2 Replies Latest reply on Jun 11, 2019 7:31 PM by Marco De la Fuente

    Administración de DataBase Oracle 11G

    3935630

      ORACLE 11g.png

      Hola a todos, soy estudiante de ingeniería informática y tengo demasiadas dudas en cuanto a la secuencia u orden lógico en que se realiza una consulta por parte del cliente, o mas bien como interactuan las memorias y procesos de la instancia SGA con la base de datos, por ejemplo si el cliente realiza una consulta de tipo select, insert, drop, alter, etc.
      Estaré muy agradecido si alguien me ayuda  comprender la secuencia en que se realiza la consulta hasta almacenarse en la base de datos.

      Muchas gracias por su tiempo!

        • 1. Re: Administración de DataBase Oracle 11G
          L. Fernigrini

          Hola, tu pregunta amerita una respuesta de varios cientos de paginas, pero voy a tratar de hacer una breve explicación

           

          1) Conexión

          Cuando una aplicación quiere conectarse a una base de datos Oracle, normalmente no lo hace en forma directa (excepto que sea algún tipo de conexión para tareas administrativas desde el mismo servidor donde se encuentra la base) si no que lo hace a través del Listener, que es un proceso que se encarga de "conectar" a los clientes (una aplicación, SQL Developer, etc. etc) con la base de datos. El proceso cliente se conecta al Listener y le pide una conexión con la base Ventas, el Listener entonces se encarga de obtener un proceso servidor (se ejecuta en el servidor donde esta la DB, a diferencia del proceso cliente) y los "conecta· entre si. El proceso cliente nunca accede ni modifica a la base de datos en forma directa, sino que todo lo realiza el proceso servidor asociado al mismo.

           

          2) Ejecutar "SELECT f.Fecha, f.Importe FROM Facturas f WHERE f.Cliente = 10"

          Cuando el proceso cliente tiene que ejecutar esta sentencia, se la pasa al proceso servidor. Este proceso se va a encargar de obtener y devolver los datos al proceso cliente. Lo primero que hace es intentar encontrar esos datos en el Buffer Cache. Al ser la primer sentencia que se ejecuta, el mismo esta vacio y no encuentra nada, por lo que el proceso servidor debe leer los datos de los datafiles (disco), los almacena en el Buffer Cache, realiza el filtrado requerido (solo los del cliente = 10) y devuelve los datos al proceso cliente

           

          3) Volver a ejecutar "SELECT f.Fecha, f.Importe FROM Facturas f WHERE f.Cliente = 10"

          Esta vez, cuando el proceso servidor recibe la sentencia. encuentra que los datos requeridos ya están en el buffer cache, por lo que no tiene que leerlos del disco (datafiles) y los puede filtrar y devolver (mucho mas rápido).

           

          4) Actualizar una factura: UPDATE Facturas SET Importe = 100 WHERE Factura=100"

          Cuando el proceso servidor recibe la sentencia, comprueba si el dato a modificar esta en el buffer cache. De no ser así, lo lee de disco y lo ubica en el Cache, donde es modificado. Guarda en el redo log buffer (memoria) información sobre como rehacer y deshacer la operación. Todo esto se hace en la memoria del servidor, y el bloque donde se encuentra la factura 100 es considerado un bloque "sucio" porque tiene cambios sin guardar en disco.

           

          Cuando el proceso cliente envía COMMIT para confirmar los datos, el proceso servidor le avisa al Log Writer (LGWR) que debe guardar en disco lo que este en el Redo Log Buffer. El proceso LGWR graba el contenido del Log Buffer a los Online Redo Log files y al terminar le confirma la operación al proceso servidor, el cual confirma el commit al proceso cliente. Los datos modificados en si están todavía en memoria (en el Buffer Cache) pero la información sobre como hacer y deshacer el cambio ya fue grabada del Redo Log Buffer a los Redo Log files.

           

          5) Actualizar una factura: UPDATE Facturas SET Importe = 100 WHERE Factura=101" y UPDATE Facturas SET Importe = 100 WHERE Factura=102"

          Ocurre lo mismo que en el punto anterior. Se modifican los datos en memoria y se guarda en el Redo Log Buffer. Al hacer commit el LGWR graba el contenido del Log Buffer a los Redo Log. Los datos cambiados siguen en memoria.

           

          En algún momento, el proceso DBWn (puede ser uno o varios) detecta que el bloque donde están las facturas 100, 101 y 102 tiene modificaciones y no ha sido guardado a disco, y se encarga de guardar el bloque en el datafile correspondiente. Esto se hace en forma periódica pero no cada vez que se hace un cambio, evitando grabar un bloque varias veces, reduciendo la cantidad de operaciones de I/O.

           

          6) Actualizar una factura: UPDATE Facturas SET Importe = 100 WHERE Factura=105"

          Igual que el punto 4

           

          7) Ejecutar 'SELECT * FROM Presupuestos WHERE Cliente = 200'

          El proceso servidor recibe la sentencia, no encuentra datos de presupuestos en el Buffer Cache, por lo que debe leer de disco los mismos y ponerlos en el Buffer Cache antes de devolverlos al proceso cliente. Pero al haber muchos presupuestos , el Buffer Cache se llena y o hay mas espacio disponible. Entonces el proceso servidor comienza a pisar en memoria los bloques donde se encuentra la información de Facturas con información de presupuestos (pisando primero los bloques que hace mas tiempo que no se consultan o modifican) hasta que llega al bloque donde se encuentra la factura 105. Al ser un bloque "Sucio" que todavía no ha sido guardado en disco, el proceso no puede pisarlo sin antes pedirle al DBWn que grabe los cambios en el datafile.

           

          8) Actualizar una factura: UPDATE Facturas SET Importe = 100 WHERE Factura=110"

          Igual que el punto 4

           

          9) El servidor se apaga por una falla en el suministro eléctrico.

          Al volver la electricidad y levantar la base de datos, la misma se encuentra en estado inconsistente (ya que la factura 110 fue modificada y se hizo commit, pero el cambio no llegó a grabarse nunca en el datafile).

          El proceso RECO se encarga de hacer el Recovery (recuperación) de la base de datos a un estado consistente. Para ello, recorre los Redo Log files (no todo el contenido, si no que tiene información en el control file que le dice desde que cambio registrado en el Redo Log no esta sincronizado con los datafiles) , aplicando los cambios descritos en el mismo. Por lo tanto, el proceso RECO vuelve a hacer el update del punto 8 (por eso el log se llama REDO, para ReHacer) dejando en el Buffer Cache el bloque donde se encuentra la factura 110 con los datos consistentes. En algún momento posterior, el proceso DBWn va a tomar este bloque del Buffer Cache y va a guardar su contenido en el datafile correspondiente.

           

          Espero que te sirva de ayuda!

          1 person found this helpful
          • 2. Re: Administración de DataBase Oracle 11G
            Marco De la Fuente

            Lisandro:

             

            Tu explicación fue fantástica.