Introduccion a la Arquitectura de Oracle. Z052 02

7,256
-1

Published on

Conozca la estructura del gestor mas potente del mercado.
Arquitectura de Oracle Database 11g, descripcion conceptual, utilizacion de la memoria, procesos especificos.

Published in: Education
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,256
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
405
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Introduccion a la Arquitectura de Oracle. Z052 02

  1. 1. Oracle Database 11g<br />> Administration I<br />ExploringtheDatabaseArchitecture<br />Explorando la arquitectura de la base de Datos<br />IZ0-052<br />Ernesto Alexander Calderón Peraza<br />http://BasesDeDatosUES.Blogspot.com<br />2<br />
  2. 2. Oracle Database Server<br />Consiste en dos elementos<br />LA INSTANCIA<br />Son estructuras de memoria y procesos<br />LA BASE DE DATOS<br />Son archivos en el disco<br />La instancia puede ser iniciada y detenida, la base de datos persiste indefinidamente<br />Los procesos de la instancia se conocen como backgroundprocess<br />
  3. 3. Arquitectura de Simple Instancia<br />La memoria es implementada por segmentos compartidos del sistema operativo, a ella se le conoce como SGA System Global Area.<br />Se reserva cuando la instancia inicia, y se libera cuando se apaga.<br />Asociados con cada proceso de servidor esta un area no compartida de memoria llamada PGA program global area<br />Los procesos de servidor se denominan Foregroundprocess, los procesos de instancia se denominan backgroundprocess<br />
  4. 4. SGA<br />PGA<br />BackgroundProcess<br />ForegroundProcess<br />
  5. 5. La estructura física que conforma una Base de Datos son los archivos de datos, el online redo log y el controlfile<br />Redo Log es un registro secuencial de todos los cambios aplicados a los datos<br />ControlFile almacena el detalle de la estructura fisica de la base de datos y el punto de inicio para enlazar la estructura fisica<br />La relacion entre estructura fisica y logica es mantenida y documentada por el diccionario de datos, que contiene los metadatos que describen la base de datos<br />
  6. 6. Arquitectura de instancia Simple<br />El proceso de usuario interactúa con un proceso de servidor<br />Es absolutamente imposible para procesos del lado del CLIENTE tener cualquier contacto con la Base de datos de forma directa, ellos utilizan procesos del lado de SERVIDOR para realizarlo.<br />Usuariointeractura con procesos de usuario<br />Un proceso de servidor interactúa con la instancia<br />La instancia interactúa con la base de datos<br />
  7. 7. Arquitectura de sistemas Distribuidos<br />Real ApplicationClusters RAC. <br />Multiples instancias abren una base de datos<br />Streams<br />Multiples Oracle Server propagan transacciones entre ellos<br />Data Guard<br />Una base primaria actualiza una base estatica.<br />
  8. 8. Real ApplicationClusters RAC<br />Provee capacidad para rendimiento, tolerancia de fallos y escalabilidad.<br />Implementa el concepto de GRID<br />Transparencia de escalabilidad viene de la habilidad de agregar instancias, corriendo sobre diferentes maquinas<br />
  9. 9. Streams<br />Razones para transferir datos de una base de datos a otra<br />Tolerancia de fallos<br />Tuning, la sincronización se vuelve automática.<br />DataWareHouse<br />Stream permite capturar cambios realizados a tablas y aplicarlos a una copia remota de las tablas.<br />Streams es bidireccional<br />Streams propaga cambios entre las dos bases de datos sincronizándolas<br />
  10. 10. Data Guard<br />Define una base de datos primaria y una o varias bases estaticas.<br />La Standby es creada a partir de un backup de la primaria.<br />Tipos de Standbys<br />Fisicos<br />Logicos<br />
  11. 11. StandbyFisico<br />Es identico al primaria byte por byte<br />Si se destruye el Primario, todos los datos se encuentran en el Standby<br />El vector de cambios aplicado al PRIMARY se propaga al STANDBY en forma de REDO record y aplicados como una restauración de backup<br />
  12. 12. StandbyLogico<br />Contiene los mismos datos que el servidor PRIMARIO, pero en una estructura de datos distinta.<br />Los vectores de cambio son propagados en forma de sentencias SQL usando el mecanismo de Streams<br />
  13. 13. Ejercicio<br />Determinando si nuestra base de datos es una instancia simple o forma parte de un sistema distribuido.<br />Conectese a la base como SYSTEM<br />SELECT parallelfromv$instance;<br />Devuelve NO si es una single Instancia<br />Selectprotection_levelfromv$database;<br />Devuelve UNPROTECTED si la base de datos no esta portegida<br />SELECT * fromdba_streams_administrator;<br />Si no devuelve tuplas STREAMS no ha sido configurado<br />
  14. 14. Estructura de la memoria<br />SGA contiene<br />Database Buffer cache<br />Log Buffer<br />Shared Pool<br />Large Pool (opcional)<br />Java Pool (opcional)<br />Stream Pool (opcional<br />PGA<br />Utilizada para las sesiones de usuario, las cuales necesitan memoria del lado del servidor.<br />
  15. 15. Database Buffer Cache<br />Es el área de trabajo de Oracle para la ejecución de SQL<br />Las actualizaciones hechas por los usuarios NO son aplicadas directamente al disco. Se aplican primero al database buffer cache.<br />BLOQUE: los archivos de datos son formateados en bloques, las tuplas y otros objetos son almacenados en estos bloques.<br />Todos los bloques contienen datos que son frecuentemente accedidos y se encuentran en el database buffer cache, ello minimiza el uso de disco para I/O<br />
  16. 16. QUE OCURRE??<br />Selectlast_name, salary, job_idfromemployeeswhereemployee_id=100;<br />Updateemployees set salary= salary*1.1 whereemployee_id=100;<br />Commit;<br />
  17. 17. Que ocurre<br />El proceso de servidor para la sesion lee el bloque que contiene las tuplas desde el archivo fisico hacia el buffer.<br />Cuando se ejecuta el commit se envia al server process la orden de ejecucion.<br />El bloque con la tupla esta disponible en el buffer para ejecutar el update.<br />Posteriormente la informacion del buffer se enviara al disco.<br />
  18. 18. Database buffer cache<br />El encargado de escribir los bloques del buffer hacia el disco es un backgroundprocess<br />El tamano del database buffer cache es critico para el rendimiento<br />El tamano del database buffer cache puede ser ajustado dinamicamente y puede ser administrado de forma automatica.<br />
  19. 19. Log Buffer<br />Es un especio pequeño que almacena los vectores de actualización temporalmente antes de ser escritos en el online REDO LOG en disco.<br />Redo Log es el mecanismo con el cual se garantiza que nunca se perderan datos.<br />LGWR es el encargado de escribir los log y es un backgroundprocess<br />
  20. 20. Como se garantiza una transacción<br />Los bloques de datos ubicados en el cache ya reflejan los cambios.<br />El vector de cambios ha sido escrito al online Redo Log en el disco.<br />
  21. 21. Shared Pool<br />Cache de Biblioteca<br />Cache de Diccionario de Datos<br />PL/SQL Area<br />Cache de resultados de consultas SQL y PL/SQL<br />Su tamaño es dinámico y puede ser automáticamente administrado<br />
  22. 22. Cache de Biblioteca<br />Library Cache<br />Es una memoria para almacenar código recientemente ejecutado, el cual esta en forma convertida (parsed), lo que facilita su ejecucion cuando es nuevamente invocada<br />Select * fromemployeeswherelast_name=‘King’;<br />Que es employees, una vista, tabla??<br />Que campos son??<br />De tipo son los campos??<br />
  23. 23. Cache de Diccionario de Datos<br />Almacena definiciones de objetos recientemente utilizados<br />Almacena definiciones de objetos cuando las instrucciones han sido ejecutadas (parsed)<br />
  24. 24. Area de PL/SQL<br />Almacena objetos PL/SQL como funciones, trigger, etc. <br />La primera vez que un objeto PL/SQL es usado debe ser leido desde el diccionario de datos.<br />Luego de la ejecucion su invocacionsera mas rapida pues estara disponible dentro del Shared Pool<br />
  25. 25. Dimensionando el Shared Pool<br />Es vital para el rendimiento, ni muy grande ni muy pequeno impacta de forma negativa el rendimiento<br />La memoria del Shared Pool es asignada por el LRU LeastRecentlyUsedAlgorithm<br />
  26. 26. Large Pool<br />Es opcional<br />Puede ser usado de forma automatica por varios procesos que toman memoria del shared pool<br />Se usa normalmente para compartir procesos de servidor, para ejecucion en paralelo<br />
  27. 27. Java Pool<br />Se utiliza únicamente si deseamos colocar código de JAVA dentro de nuestro servidor<br />Es posible colocar Enterprise JavaBeans<br />
  28. 28. Streams Pool<br />Mecanismo utilizado por Streams para extraer vectores de cambio desde el online REDO LOG formar la reconstruccion de las consultas que seran ejecutadas.<br />
  29. 29. Verificar el uso de memoria<br />Conectese como SYSTEM<br />Select COMPONENT, CURRENT_SIZE, MIN_SIZE, MAX_SIZE fromv$sga_dynamic_components;<br />
  30. 30. Procesos<br />En Unix los procesos son separados por el sistema operativo, en Windows todos aparecen como un proceso denominado ORACLE.EXE<br />SMON System Monitor<br />Tiene la tarea de montar y abrir la base de datos.<br />Luego se encarga de tareas domesticas como la paginacion de espacio libre en datafiles<br />
  31. 31. Procesos<br />PMON Process Monitor<br />una sesion de usuario es un procesos que se conecta a un proceso de servidor<br />Si una sesion termina anormalmente PMON destruye el proceso de servidor, devuelve la memoria usada y hace ROLLBACK a las transacciones pendientes<br />
  32. 32. Procesos<br />DBWnDatabaseWriter<br />Encargado de escribir de los buffer de Database a los archivos en disco.<br />Cada proceso es llamado DBW0, DBW1… uno por cada CPU<br />La lectura I/O es mala para el rendimiento.<br />DBW selecciona los DIRTY BUFFERS y los escribe en el disco, elije aquellos que no han sido recientemente utilizados.<br />Dirty Buffers: <br />contienen información que ha sido modificada pero que todavía no se escribe en disco<br />
  33. 33. Que ocaciona que DBWn escriba?<br />Que no exista buffer disponible<br />Que hayan muchos Dirty Buffer<br />Una espera de 3 segundos<br />Un CheckPoint<br />Este obliga a que todos los dirty buffer sean escritos<br />Ocurren siempre que se apaga la base de datos<br />
  34. 34. Procesos<br />LGWR Log Writer<br />Escribe el contenido del LOG buffer para los archivos de log en el disco<br />Antes de aplicar cambios encontrados en el database buffer, el vector de cambios se aplica al log buffer<br />Cuando el LGWR escribe el log buffer en disco<br />cuando una sesion hace un commit<br />Si el log buffer llega a un tercio de su capacidad<br />Cuando se escriben Dirty Buffers<br />
  35. 35. CKPT checkpointprocess<br />Checkpoint son necesarios para evitar que la instancia falle, y si lo hace recuperar la base de datos rapidamente.<br />MMON Manageability Monitor<br />Brinda capacidad para monitoreo y ajuste de la Base de datos<br />Captura estadisticas desde el SGA y las escribe en el diccionario<br />Monitorea la base de datos y la instancia chequeandolas por cualquier alerta.<br />
  36. 36. MMAN memory manager<br />Encargado de la administración automática de la memoria<br />Monitoriea la demanda de la memoria SGA y pude redimensionarla si es necesario<br />ARC el Archivador<br />Opcional. Para preservar el historial de todos los cambios aplicados a los datos.<br />Se encarga de garantizar la disponibilidad y exactitud de los archivos Online Redo log files<br />
  37. 37. RECO Recovererprocess<br />Una transacción distribuida involucra actualización de dos o mas bases de datos.<br />Updateemployees set salary= salary*1.1 whereemployee_id=1000;<br />Updateemployees@dev set salary=salary*1.1 whereemployee_id=1000;<br />Commit;<br />En la aplicación cada LGWR flush el log buffer hacia el disco y confirman la transaccion, si ocurre un problema RECO cancela la transaccion y hace Rollback en las dos bases de datos<br />
  38. 38. Estructura Fisica<br />CONTROLFILE<br />ONLINE REDO LOG<br />DATAFILES<br />Archivos externos<br />Archivo de parametros de inicializacion<br />Archivo de password<br />Archivo Redo log<br />Alert Log y Trace Files<br />
  39. 39. Controlfile<br />Es un puntero para la base de datos, la ubicación del online redo log y de los archivos de datos.<br />Almacena informacion requerida para mantener la integridad de la base de datos (secuencias criticas y timestamps)<br />Mide algunos megas de tamano pero es indispensable<br />
  40. 40. Online Redo Log File<br />Almacena una bitácora de cada vector de cambio aplicado a la base de datos.<br />Consiste de grupos de online redo log files, cada archivo se conoce como un miembro.<br />Los cambios son escritos al actual online redo log file por LGWR<br />El tamano para un grupo es de 50mb<br />
  41. 41. Data Files<br />Uno para el tablespace SYSTEM y otro para SYSAUX<br />Son el repositorio fisico para los datos<br />Un segmento es una estructura de almacenamiento de datos.<br />Desde el sistema operativo, es un grupo de sistemas de bloque, cada uno numerado consecutivamente.<br />El tamano varia desde 2kb hasta 4kb<br />
  42. 42. La Estructura Lógica<br />Oracle utiliza el temino de segmento para describir cualquier estructura que contiene datos (tablas, tuplas, indices, etc)<br />Un TableSpace es una colección logica de uno o mas segmentos, y fisicamente una colección de uno o mas datafiles.<br />Una tabla puede contenerse en varios datafiles, y un datafile puede contener bits de muchas tablas.<br />
  43. 43. Diccionario de Datos<br />Son los metadatos. Describe la base de datos tanto física como lógicamente.<br />Se almacena con conjuntos de segmentos dentro de los tablespace SYSTEM y SYSAUX<br />Para consultar el diccionario existen vistas, con el prefijo: DBA_, ALL_, USER_, etc.<br />
  44. 44. ejercicio<br />Createtable tab24(c1 varchar2(10));<br />Selecttablespace_name, extent_id, bytes, file_id, block_idfromdba_extentswhereowner=‘SYSTEM’ and segment_name=‘TAB24’ ;<br />

×