Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduccion a la Arquitectura de Oracle. Z052 02

7,920 views

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
  • Be the first to comment

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 />

×