Arquitectura Oracle

download Arquitectura Oracle

of 15

Transcript of Arquitectura Oracle

Arquitectura Oracle

Una vez el usuario fue atendido por el listener, se abre una conexin(mediante un puerto, extrado de un rango preestablecido) directa con la BD, recordar que durante la instalacin del software de la base de datos, se realizo una configuracin en el kernel para afinar sus valores entre ellos establecamos los puertos que poda usarc para este propsito, una vez realizado la conexin al usuario se da de baja para el listener. Ojo: Estamos suponiendo que el servidor de bd est en modo dedicado!!! Cuando se estable la conexin se establece un proceso( server process enel lado servidor ) del SO dedicado a atender una sesin especifica de la BD. Si hubieran 100 usuarios habra 100 server process. El server process interacta con otros componentes de la bd para luego el ser el que enva la informacin procesada al usuario. UserProcess(proceso - lado del usuario)se encarga de realizar las peticiones en representacin del usuario logeado en la bd.

Haciendo un zoom a la BD. La bd tiene 2 componentes una es la instancia (memoria RAM) y otra es la parte fsica (la BD- archivos en el SO)

La Instancia

PGAEs memoria privada, solamente el usuario puede usar, escribir y leer sobre su propio pga. Un PGA se divide en Private SQL Area(pequea rea donde se guarda todas las definiciones de nuestros cursores a nivel de sesin, si est abierto , cerrado, declaracin de variables de plsql, tipos de arreglo y tipos de datos- la definicin, adicionalmente informacin de la sesin como datos del usuario) y. El WORK AREA (Va el tema de ordenamientos, group by, order by, join , ndices de tipo bitmap, van a consumir la memoria del workArea). Referencia (el pga se reasigna inteligentemente entre todas las sesiones): Si todo el pga es superior de 1 gb de Ram, el WORK AREA (POR DEFAULT) no superara los 200 MB de RAM para una sesin especificada. Ojo un usuario puede tener varias conexiones, por tanto varias sesiones abiertas. Parmetro que asigna tamao total del pga es pga_aggregate_target.

SGAEl SGA es memoria compartida, recordemos que se a seteado en el Linux(kernel shmax,shmni,shmnl en el SYSCTL.CONF ). COMPONENTES: BUFFER CACHE: Van todos los registros ledos desde disco, con la finalidad de obtener un mayor rendimiento. Pero ojo que esta memoria tiene un lmite, para este caso se usa un algoritmo denominado LRU para empezar a liberar espacio(bajando registros) que es usado menos frecuentemente. Nota: Es el serverprocess que al encomendrsele una consulta SQL( es decir el usuario hizo la consulta y se la enva mediante su userprocess), pregunta al buffer cache si ya tiene esos registros requeridos por el select si no lo tiene por qu es la primera vez que se la consultan en el da, entonces oracle va al disco duro, lee los archivos correspondientes trae los registros y los almacenara en el buffer cache, una vez ah el server process se sirve y puede entregar los resultados. La siguiente vez si se hiciera una consulta para obtener los mismos registros, directamente podrn estar disponibles en buffer cache y no requiere bajar a disco. Obs: Con respecto al rendimiento entre mayor cantidad de RAM(buffer cache) vs Tiempo de respuesta de la BD. Tiempo de respuesta = CPU Time + WAIT EVENT (lecturas a disco, interbloqueos, un server procces espera los resultados(trayendo datos al buffer cache, liberando espacio), etc). Existen diversos factores o eventos de espera que pueden causar un respuesta tardada, habr que hacerse un anlisis detallado para encontrar la cusa probable del tiempo de respuesta retardado de la BD.

SHARED POOL Est conformado por varios subcomponentes. Data Dictionary Este componente no es modificable por nosotros, ya viene de fabrica sellado, entre versiones puede cambiar. En esta se guarda todas las vistas v$xxx__ . Library Cache Cuando se enva un query al bd, el motor determina como lo va a trabajar, entonces se le aplica un funcin F(x) sobre esta y resulta un cdigo AB8561510. Si llegara otra consulta se armara un cdigo diferente. Basado en este cdigo se Oracle consulta al library cache, y se le pregunta si tiene como se a resuelto este query con este cdigo, sino lo tiene, entonces oracle en pocos segundos va comenzar a analizar cmo resolver este query, podra hacerlo mediante un fullScan, puede trabajar con un ndice formado por el departamento, nombre del empleado o por el sexo, puede tomar multiples caminos, Oracle tiene poco tiempo para determinar cul es el mejor plan (el plan mas barato)de trabajo, el que le va costar menos tiempo, menos consumo de CPU, menos costo de lectura de disco y menos memoria, una vez determinado(el plan de trabajo) este amarra el cdigo y lo anexa al plan de trabajo hecho esto se almacena el plan de trabajo en el libraryCache y Oracle empieza a resolver el cdigo : identificara los registros a traer los llevara al buffer cache y se realiza la secuencia conocida al final llegara al usuario.

Nota: Sola la parte de analizar cul es el plan de trabajo para Oracle es muy costosa y esto se traduce en consumo de CPU, y si Oracle se detiene a pensar a cada momento cual es el mejor plan de trabajo esto quiere decir de que el library cache es muy reducida lo que lo obliga a retener solo unos pocos planes de trabajo y tener que descartarlos cuando se generen nuevos planes sucesivos. Una de las soluciones es aumentar el SharedPool que dinmicamente asignara mayor espacio de trabajo al Library cache. Si en el momento de la ejecucin se revisa el bufferCache y si tiene la informacin no har falta bajar a disco. La funcin F(x) mencionada toma en cuenta el texto del query, entonces si se hace la misma sentencia pero con tamao de letra distinto a pesar que tuviera

el mismo resultado se le dar un tratamiento completo obligando a generar un nuevo plan de ejecucin para el mismo query con diferente escritura. La v$sql_area nos permite identificar cuales con los querys que se comportan de la forma explicada sin preparedstatement, generando diferentes planes de ejecucin. El parmetro cursor_sharing seteado a similar (por default exact ) nos permite evitar el comportamiento daino mencionado antes. Mayor rendimiento con el parmetro en exact y trabajando on los preparedStatement . Obs: Phisical write : Se muestra en los reportes(eventos de espera de la sesin , reportes de afinamiento, y en los planes de ejecucin de los query) cuando la informacin no fue encontrada en el buffer cache y tuvo que bajar a disco Logical write: Se muestra cuando la informacin si la encuentra en el buffer cache y se la entrega directamente al usuario. Hard parse: Se muestra cuando Oracle no logra encontrar un plan de ejecucin por tanto tiene que empezar a desarrollar. Soft parse: Cuando si logro encontrase el plan.

ASH (Active sesin history a partir de la versin 10g) Guarda la informacin por segundo de cada sesin que est en la bd de forma activa (sea realizando query o cualquier otra actividad), sirve para luego pueda entregar algunos reportes de performance de QUIEN FUE EL CULPABLEEE!! (Guarda la sesin y el query que se est ejecutando por segundo).

RESULT CACHE (a partir de la versin 11g) Tiene dos partes SQL Y PLSQL: Se guarda resultados de operaciones(no la filas-registros!!) ejemplo SQL : Select sum(salary) from employe . El resultado de SUM va a guardarse en el resulta cache. Ojo!! deben trabajarse con funciones determinanticas(aquellas que basados en los mismos inputs devuelven el mismo resultado), length, substring, etc, todas aquellas que devuelvan un resultado ORACLE automticamente a penas exista una operacin dml sobre una tabla involucrada en un resultado almacenado en el result cache es invalidado, ya que ese resultado sera incorrecto, haciendo que Oracle tenga que recalcular cuando se vuelva consultar por el mismo valor.

LARGE POOL Es un pool disponible a partir de la versio 8i, este pool es un pool si quieren no lo tienen habilitado, pero acorde a las actividades de la bd obliga a que este habilitado por problemas de performance. Sirve de apoyo al shared pool. Cuando se saca un backup o restored con el RMAN(utilitario), si no est presente el large pool o se queda corto se empieza a usar memoria del shared pool, y se ve afectado el library cache y comienza haber varios reparses de los planes de ejecucin. Cuando se usa paralelismo select /*paralel*/ xx from yyy, hay un coordinador que empieza a juntar las distintas tareas de cada hilo, para esta tarea se usa el large pool. Para las interfaces XA, por ejemplo cuando una aplicacin requiere recurrir a mltiples bd (oracle, sqlserver y postgree) para completar el proceso la transaccin debe insertar datos en las 3 bd, si en una de ellas ocurre una falla por ejemplo db2, entonces la transaccin completa se anula, comenzando hacerse rollback en cada una de ellas, esto para transacciones distribuidas. Para estos casos se usa interfaces XA y se usa memoria del LARGEPOOL.

REDO LOG BUFFER Guarda todos los cambios que ocurren dentro de la bd oracle, todas las operacin DML, DDL y DCL ( grant y revoke), automticamente estas sentencias son almacenadas en el redo log buffer, con la intencin del propsito de recovery (recuperacin), esta informacin constantemente va bajando a disco. Y se usa junto con el backup para recuperar las acciones no almacenadas en el despus del backup.

JAVA POOL Es un componente que solamente deben setearlo cuando se hacen desarrollos en java, se pueden crear clases de java y estas pueden registrarse dentro de la bd , con lo cual las funciones miembro de la clase java pueden utilizarse como procedimiento de oracle, a estas funciones se les conoce como javaProcedures. Por lo general se usan(se instancian new ) estas clases java es cuando los procedures(lenguaje plsql) se quedan cortos es entonces cuando se usa el poderoso lenguaje java, para superar las barreras. La versin 10g trabaja con con jdk 1.4 y la 11g con el jdk 1.5 no hay forma de hacer un upgrate. Ojo es un java limitado, no hay swing ni awt, y otras restricciones. STREAMNS POOL Es un componente disponible desde la versin 10g , habilitarse cuando se usa oracle stremns, que nos permite hace replicacin muy superior a lo hecho con vistas materializadas hechas para el trabajo de sql fundamentals.

Oracle streamns (versin estable Oracle 9.2.07), es un producto que nos permite replicar a nivel esquema, por ejemplo replicacin de definicin de stored procedures, es bidireccional(origen y destino intercambiable), heterogneo (entre diversos SO AIX Y HP UX). es

Oracle compra el producto Golden Gade, para replicar entre BD ORACLE Y SQLSERVER O MYSQL O DB2, ETC. Este reemplazara a oracle streamns.

BASE DE DATOS (archivos de la BD-Fisico):

PARAMETER FILE Guarda la configuracin de la instancia, cuanto ocupa cada una de las estructuras de memoria(todas), adems de el numero de sesiones de la bd, cuantos procesos, ubicacin del control file, etc. Existen 2 tipos pfile y spfile, el primero al modificarlo hay que grabarlo en un block de notas, vi, etc. y para que tengan efecto hay que reiniciar la BD, el segundo es un binario y solo admite cambios por comandos online(de 300 parmetros , 200 son modificables por comandos), disponible desde la versin 9i, antes se est obligado a usar el pfile. Si existen ambos archivos se da prioridad al spfile.Al menos debe estar uno de ellos. Si no est presente Oracle no sabe crear las estructuras de memoria.

CONTROL FILE Guarda informacin CRITICA(Tener al menos 5 copias de seguridad!!), guarda meta-data de la BD , es decir, el nombre de la bd, que archivos componen la b, donde(ubicaciones !) estn estos archivos de la BD, informacin de carcter set , national carcter set, el valor del scn. Normalmente ocupa entre 10 a 40 Mb. REDO LOG FILE Guarda todos los cambios que ocurren en la BD, del redo log buffer se almacenara el contenido en este redo log file, que en el futuro van a ser los archive (arkai). DATA FILE Guarda la informacin de nuestros tablas del negocio,metadata de vistas, ndices, definiciones de los stored procedures, todo la informacin que manejamos a nivel de segmentos se guardan en los data files. PASSWORD FILE Guarda el password del usuario SYS, adicionalmente guarda la relacin de usuarios que tienen los privilegios de SYSDBA, SYSOPER y SYSASM.

ALERT LOG

BACKGOUND PROCESS Responsables de llevar la informacin que est en memoria y coordinarla y guardarla en los archivos de BD.

REDO LOG WRITE Responsable de grabar la informacin de redo log buffer al redo log file, con una frecuencia de 3 segundos, cuando el buffer est escrito a 1/3 de lleno (extra oficialmente se ha confirmado que a partir de 10g es a 1/6 de lleno), o 1 mb de actualizaciones y por ultimo cuando se ejecuta un commit automticamente el REDO LOG WRITER comienza la bajada.

Nota: Al realizar el commit el pront pasa al log writer y solo cuando este cumple con su tarea se retorna el pront al usuario, aunque para bd livianas no se siente el efecto para BD cargadas puede llegar a tardar en regresar el pront, se recomienda evitar realizar los multiples commit Recuerde que esa demora pasaran hacer WAIT EVENTS que retardan los tiempos de respuestas de la BD. A partir de la versin 10g hay diversos commits, normal, batch, batch immediate (este devuelve el pront y el log writer escribir en el fondo), etc

DBWRITER Bajara la informacin del buffercache a los datafiles, lo baja con cierta frecuencia , cuando est lleno el buffercache, cuando se hace un drop index o drop table, tambin un evento de chek point hace que el dbwriter empiece ha trabajar. CHECK POINT PROCESS Su responsabilidad es homologar las cabeceras de cada Data Files con el scm correcto, pasando la BD a estado consistente. Como??, para lograr hacer esto , baja todo lo que hay en el redo log buffer y el buffer cache, para eso hace trabajar al dbwriter y este le enva la seal para que el log writer haga lo suyo antes, luego el buffer y listo check point completado. Cuando ?, cuando la BD baja limpiamente (SHUTDOWN IMMEDIATE, NOO SHUTDOWN ABORT), tambin cuando el tablespace cambia de modalidad(offline, online, backup , no backup, read only, write line), tambin por defecto cada 1800 segundos(configurable!!) el proceso de chekpoint entra a trabajar, en el evento SWITCH DE REDO LOG tambin activa el proceso de chekpoint.

Si la BD se cerr a la mala(si se cerr bien se hizo chekpoint, entonces todos los scn son iguales), y solo logro almacenarse la info en el redo log file, pero no as en los data files(no hubo check point!!), en las fases del proceso de iniciacin de la la bd, si Oracle detecta este problema (verifica el scn del control file, y compara con la cabecera de cada data file), basta que uno solo tenga un valor diferente al del control file, entonces lanza inmediatamente el protocolo de Instance recovery. El instance recovery (lee el scn almacenado en el control file!!) es el encargado de regularizar la cabecera de todos los datafiles con un mismo scn, recurriendo a los redo log files almacenados, para poder reproducir los cambios no guardados en los datafiles, si el recovery requiere los arkay ya requiere un configuracin especial y manual. El responsable de hacer todo el proceso de instance recovery es el SMON. El SMON (SYSTEM MONITOR) tiene tambin la responsabilidad de liberar espacios temporales (tablas temporales, ordenamientos que estn rondando inutilizados). Cuando se levanta la DB y hubo una cada sucia se activa el SMON.

PMON Bsicamente (alguien le desconecto el cable de red y no termino la transaccin (update de 5000 registros que no se pudo culminar !!) en curso de una sesin, Qu sucede con los registros que se estaban usando, quedaran bloqueados por siempre?,) se encarga de identificar aquellas sesiones que se cerraron abruptamente y va a comenzar hacerle rollback a todas las acciones que tena pendiente esa sesin que no puedo hacerlo por haber salido por a o b motivo, sea es el responsable de liberar recursos que esa sesin estuvo consumiendo. Supongamos que tenemos dos servicios colgados en el listener QAS y PRD, el listener puede ser registrados manualmente y tambin hay una forma de registro dinmico de servicio, y el PMON es el responsable de registrar dinmicamente. MMON(Disponible desde 10g-7 das) Sale y toma fotografas cada hora, servirn para sacar diagnostico de performance (sus tiempo de respuesta, cantidad de usuarios, cuales son los querys mas pesados, como estn tus buffers ), es un radiografa de cmo est la BD, y se guarda durante 8 dias(11g - configurable). Permite responder preguntas sobre el estado de la BD en tiempo pasado, todo se guarda en disco. MMAN (memori manager) En la antigedad el dba tena que empezar a monitorear cada pool de ram, y tena que el mismo administrarlo y regularlos, si vea que un pool tena poca memoria, pedia una ventana y quitarle memoria a un pool y ponerle a otro, desde Oracle 9i oracle administra de forma inteligente toda la PGA, pero los pool del SGA aun tena que administrarlo manualmente, pero a partir de Oracle 10g oracle administra de forma inteligente y dinmica(de acuerdo a la situacin!! : )) toda la SGA. Nota: El MMAN es el ejecutor, y se basa en la informacin que el MMON extrajo de la bd, hay un 3er proceso que realiza las labores de anlisis que decide cuando realiza los cambios dinmicos en cantidad de memoria de cada pool. En el 11g, solo pide informacin de memoria y reasgina dinmicamente entre PGA Y SGA.

MMNL Lo que hace es bajar informacin del ASH a disco. RECO Solo existe en transacciones distribuidas, funciona cuando una transaccin deba insertar en dos tablas de diferentes bd Oracle(mediante dblink), apenas Oracle reconoce que se lanza una transaccin distribuida lo que hace desde el origen crea un reco de tipo coordinador(en el origen) y este conversa con el reco local (origen), este chekea remotamente si es que la transaccin se a completado con xito, de no ser as le comunica al reco coordinador (que no termino la transaccin )y este ultimo aplica un rollback tanto en la bd local como en el remoto. Sirve para validar si la transaccin remota se ha llevado con xito.

MODO

ARCHIVE(ARKAI)

Haciendo un zoom a los redo log file. Los redo log file estn compuesto por grupos, por defecto 3(100 mb cada grupo), pero lo recomendable es tener hasta 6 grupos. Sabemos que la informacion que viene de redo log buffer, baja a los redo log file, pero estos estan catagorizados por grupo, tienen un archivo y se les a asignado un cierto

tamao de almacenamiento. Los redo log file tienen estados (current: es el grupo que actualmente esta recogiendo informacion del redo log buffer, inactivo y activo), el redo log buffer va a descargar su informacion en aquel redo log grup que esta en estado Current(solo uno puede estar current a a la vez), entonces el redo log writer empieza a bajar la informacion. Cuando el primer grupo llega a cumplir con su max tamao de almacenamiento, tendra que pasar la posta al siguiente grupo redo(ha esto se le considera como switcheo de redo log file) y ahora el redo 2 group esta en estado acctivo y el anterior pasara a inactivo no olvidar que al haber un switch se activa el proceso de CHEK POINT. Luego este 2do redo log group se llena entonces nuevamente se realiza el switch y asi tambien para el tercero. Cuando se llenan los 3 redo log group y se vuelve a pasar la posta al redo log group inicial, (OJO ESTO EN MODO NO ARCHIVE), se chanca la informacion almacenada en este y a reemplazarla con las nuevas transacciones.

MODO ARCHIVE Sigue el mismo proceso explicado excepto que cada vez se pase la posta al siguiente grupo REDO, Oracle automticamente en fondo incia un proceso que va sacar una copia de respaldo del redo log que est lleno y lo va a guardar en un directorio especial (/u03, en este se guardaran los duplicados de los redo log llenos, seteado durante la instalacin, se le conoce con el nombre de fast recovery area fra!). OBS: Cada vez que hace el switch, Oracle saca la copia de respaldo en cada cambio, as sucesivamente, y cuando regresa al primer grupo redo, pregunta si ya se ha sacado la copia del grupo inicial, si es as entonces Oracle lo chanca con las nuevas transacciones. El punto a considerar es que dar la vuelta por los redo

puede ser ms rpido de la ejecucin de escribir en disco (hd lentos!!), si es as los usuarios van a sentir que su commit demora, entonces este puede convertirse en un evento de espera(WAIT EVENT). El back ground process que se encarga de hacer esta copia de respaldo en el Archive process. El modo archive nos permite nos permite recuperar la bd hasta la ultima transaccin commiteada.(**)

** Supongamos que se llena el ultimo redo log group y se graba el archive, pero inesperadamente la bd se corrompe y muere , pero supongamos que tenamos un backup que acabo a las 3 59 pm, entonces estando en modo archive , tenemos que restaurar el backup vigente, pero aun as no tenemos todas las transacciones que se realizaron desde las 3 59 a 5 40, luego debemos recurrir a la bitcora de los archive , que tiene todas las transacciones pasados durante todo el tiempo, entonces Oracle nos permite recuperar la informacin hasta la ultima transaccin COMMITEADA. *** Por esto es muy recomendable que en BD de Produccin debera estar en MODO ARCHIVE.