Cerrar

Enviar mensaje

twitter FaceBook You Tube Git Hub Docs.com Enviar email

Manual de Administración de Bases de Datos

[2]
Arquitectura de Oracle Database

Publicidad

[2.1] comunicación con los servidores Oracle Database

[2.1.1]elementos de la comunicación con un servidor Oracle

Para comunicar con el servidor de bases de datos, Oracle Database proporciona un sistema de al menos dos capas. Lo que implica a un cliente y a un servidor, los cuales utilizar alguna red de computadoras para conectar. Sin embargo es muy habitual que entre la capa del cliente y la del servidor haya que atravesar otra capa, formando un modelo de tres capas (según lo visto en el capítulo anterior). La Ilustración 12 resalta los elementos más importantes en la comunicación cliente/servidor de Oracle:

La comunicación entre el cliente y el servidor se realiza a través de dos procesos:

Normalmente, hay un proceso servidor para cada usuario que conecte con la base de datos. Es decir, si hay diez conexiones, habrá diez procesos de usuario y diez procesos servidores.

Oracle, no obstante, proporciona un modo de trabajo llamado servidor compartido, en el que un mismo proceso servidor atiende a varios procesos de usuario. La razón es ahorrar memoria, aunque no sea tan eficiente como el modo dedicado.

[2.1.2]sesión y conexión

Hay dos elementos en la comunicación cliente/servidor que conviene diferenciar:

En principio, la forma de trabajar de Oracle Database es la que se conoce como modo de servidor dedicado. En ella por cada proceso servidor atiende a un único proceso de usuario. Dicho de otro modo, hay tantos procesos servidores como procesos de usuario.

Sin embargo existe la posibilidad de trabajar en modo de servidor compartido. En este caso cada proceso servidor atiende a varios procesos de usuario. Uno, o más, procesos, llamados dispatchers (repartidores), se encargan de asignar a cada proceso de usuario el proceso servidor adecuado.

En este modo se ahorra memoria, ya que la memoria de usuarios se almacena en la zona global compartida (llamada SGA).

[2.1.4]establecimiento de conexión

La conexión típica a Oracle comienza con una petición de acceso desde el lado del cliente.

Un proceso conocido como Listener, consigue “escuchar” dicha petición. El Listener es uno de los elementos fundamentales de Oracle Database. Su labor es gestionar el tráfico de las peticiones del cliente.

Una vez el Listener detecta la nueva petición, se establece conexión y comenzarán a comunicarse el proceso de usuario con su proceso servidor correspondiente.

El Listener se mantiene escuchando la comunicación (observar Ilustración 15).

[2.2] funcionamiento de la instancia de Oracle

[2.2.1]arquitectura general de Oracle Database

Un servidor Oracle Database es el conjunto formado por estos dos elementos:

Un servidor de Oracle puede poseer más de una instancia, pero en general en estos apuntes trabajaremos bajo la hipótesis de tener un sistema de instancia simple. Las instancias múltiples se dan en sistemas distribuidos, en los que es posible disponer de más de una instancia (alojada en diferentes servidores) para la misma base de datos.

La Ilustración 15 resume la arquitectura de Oracle. En ese diagrama las elipses representan procesos, los rectángulos son almacenes de datos en memoria RAM y los cilindros, archivos en disco.

[2.3] estructuras en memoria de la instancia de Oracle

[2.3.1]elementos de la memoria

Ilustración 16. Elementos de la memoria de Oracle. Se resaltan los principales componentes internos así como la comunicación entre el proceso cliente y el proceso servidor y su relación con la PGA y la SGA.

Como ya se ha comentado, una instancia está compuesta por las estructuras de memoria en las que se graban datos y por los procesos que dan servicio a la base de datos.

La Ilustración 16 muestra el detalle de los componentes de la instancia. Cada proceso servidor (si el modo de trabajo es dedicado) atienden cada uno a un usuario.

Los datos en la instancia poseen dos grandes estructuras de almacenamiento:

Pasamos, a continuación, a detallar los elementos de la instancia de Oracle. Inicialmente empezaremos por los elementos de la memoria y después detallaremos los principales procesos.

[2.3.2]componentes de la PGA

Como se ha comentado, la PGA contiene datos necesarios e independientes para cada proceso servidor. La información que contiene permite acelerar el proceso de las instrucciones SQL del clienteLa PGA se divide en dos zonas:

Como ya se ha comentado, en el caso de utilizar un modo de servidor compartido hay datos que pasan a la SGA. Concretamente, la UGA pasará a la SGA y las PGA de cada conexión almacenarán solo el espacio de pila.

[2.3.3]componentes de la SGA

1Pool Compartido (Shared Pool)

Se trata de una zona de memoria utilizada para acelerar la ejecución de las instrucciones SQL y PL/SQL.

Su espacio se divide en:

2Caché de Búferes de Datos (Database Buffer Cache)

Está dividida en bloques (más adelante se explica lo que es un bloque de base de datos) y es la estructura (normalmente) que más ocupa en la SGA. Oracle Database intenta que la modificación de datos en el disco tarde lo menos posible. La estrategia principal es escribir lo menos posible en el disco.

Por ello cuando una instrucción provoca modificar datos, inicialmente esos datos se graban en esta caché. La grabación ocurre tras la confirmación de una transacción. Después, cada cierto tiempo, se grabarán todos de golpe en los ficheros de datos (concretamente cuando ocurra un checkpoint).

Los datos, aunque no estén grabados realmente en disco, serán ya permanentes y aparecerán en las consultas que se realicen sobre ellos, además esas consultas serán más rápidas al no acceder al disco. Esto último es la segunda idea, que los datos a los que se accede más a menudo, estén en memoria y no se necesite leerlos del disco.

Los búferes de la caché se asignan con un complejo algoritmo basado en LRU (Last Recently Used) que da prioridad a los búferes que se han utilizado más recientemente.

Cada búfer puede estar en uno de estos estados

Además, con respecto al acceso, los búferes pueden tener estas dos situaciones:

La lectura de búferes sigue este proceso:

[1]Si necesitamos un dato, se le busca en esta caché. Si se encuentra se entrega, siempre y cuando no esté ocupado por otro proceso (pinned).

[2]Si el dato requerido no se encuentra en el búfer, ocurre un fallo de caché. Este fallo implica leer los datos del disco y pasarlos a memoria (los búferes necesarios se marcarán como búferes limpios).

[3]En ambos casos, si la instrucción implica modificar los datos de ese búfer, se modifica y pasa a ser un búfer sucio.

[4]Cuando ocurre un checkpoint, el proceso DBWn, graba búferes sucios a disco (lo mismo si se detecta que quedan pocos búferes limpios o sin uso) y se marcan como búferes limpios.

Otro detalle de esta zona de la SGA es que los búferes se agrupan en fondos de almacenamiento (Pools). Estos fondos son:

3Búfer de Redo Log

Se trata de un búfer circular. Se van utilizando los bloques y, cuando se han usado todos, se vuelven a reutilizar los primeros en caso necesario y así continuamente.

Su función es almacenar la información acerca de los últimos cambios (DML confirmados y DDL) realizados sobre la base de datos. Esta información se vuelca continuamente, mediante el proceso LGWR, a los archivos de datos.

Los Redo Log son necesarios para recuperar los datos que no han podido ser grabados definitivamente en disco (normalmente por ocurrir una situación de excepción antes de un CHECKPOINT).

4Pool Grande (Large Pool)

Área opcional de la SGA que proporciona espacio para los datos necesarios para realizar operaciones que impliquen muchos datos:

Esta área de memoria no ocupa bloques usando el algoritmo LRU (a diferencia del Pool Compartido y de la Caché de Búferes de Datos), sino que los bloques quedan asignados hasta que queden marcados, por el proceso que los utilizó, como libres para otros procesos.

5Pool de Java

Sólo se usa para los programas que utilizan Java.

6Pool de Streams

Lo usa sólo el componente Oracle Streams (utilizado para bases de datos distribuidas) y sirve para almacenar en búferes, datos manejados por dicho componente.

[2.4] procesos de la memoria de Oracle

[2.4.1]tipos de procesos

Los procesos servidores atienden a los procesos de usuario. Sus labores fundamentales son:

Los procesos en segundo plano se ejecutan al lanzar la instancia de Oracle y quedan residentes en memoria realizando diversas labores en el servidor. La vista V$DBPROCESS permite obtener información de los procesos en memoria.

A continuación se detallan las acciones de los principales procesos.

1DBWn.

El proceso de escritura de base de datos (DataBase Writer Process) DaEscribe los bloques modificados del buffer de cache de la base de datos (dirty buffers) de la caché de búferes de datos de la SGA a los archivo de datos en disco. Eso no ocurre en todo momento, sino cuando se produce un evento de tipo checkpoint.

El hecho de que esto se haga solo cada cierto tiempo (el tiempo establecido para el checkpoint) se debe a que, de otro modo, el funcionamiento del servidor sería muy lento si se accediera más a menudo al disco.

La n en el nombre (DBWn) indica que no hay un solo proceso DBW, sino que puede haber hasta 20 dependiendo de la potencia del servidor (DBW0, DBW1, …). En un sistema con un solo procesador lo lógico es que haya solo uno. El parámetro de sistema DB_WRITER_PROCESSES se encarga de definir el número de procesos DBWn.

La escritura en disco de los bloques sucios ocurre si:

DBW escribe los búferes en disco en lotes, para ganar eficacia. Al grabar los datos, graba el número de secuencia de cambio (SCN) en el disco. Este número indica la transacción que se está grabando. Como en los Redo Log también se usa esa secuencia, los datos grabados en los Redo Log y en los ficheros de datos se pueden comparar y saber qué archivos están más al día (siempre estarán más actualizados los Red Log) y así, en caso de recuperación, determinar los SCN que faltan.

Como se ha dicho antes, se graban los datos cuando ocurre un checkpoint o cuando faltan bloques para asignar en la caché de búferes de datos. En realidad en ambos casos, diremos que ha ocurrido un checkpoint.

Hay dos formas de actuar de DBW, la diferencia está en el tipo de checkpoint que le llega. Hay dos tipos: checkpoint incremental y checkpoint total (cuando se habla de checkpoint a secas, nos estaremos refiriendo a este último).

La cuestión es que puede haber miles y miles de búferes ocupados para ser guardados en los archivos de datos, lo que supone que esa sea una tarea larga y, por lo tanto, peligrosa porque durante todo el tiempo de escritura, un error crítico podría dejar la base de datos corrupta y no funcionar.

Los checkpoints incrementales sólo escriben unos cuantos búferes sucio marcándolos como libres, así el tiempo de grabación es más rápido.

Sólo cuando llega el checkpoint de verdad, el total, se graban absolutamente todos los búferes sucios. Esto ocurre menos a menudo, por lo que el riesgo de que se corrompa el disco, es menor.

DBW actúa si ocurre una de estas circunstancias (las tres primeras se corresponden a un checkpoint incremental y solo la última es un checkpoint total):

[1]No hay búferes libres en el búfer de datos de la SGA para seguir almacenando información; es decir, la caché de datos está a tope de ocupación. Si esto ocurre, Oracle escribe unos cuantos bloques sucios en los archivos de datos para poder liberar la ocupación de la memoria y disponer de más búferes libres.

[2]Hay demasiados bloques sucios. En ese caso se escriben unos cuantos bloques sucios en disco para liberar espacio. Es un caso previo al anterior que se basa en una medida de ocupación preventiva para no esperar a que no haya búferes libres, que sería más dramático.

[3]Se cumplió el tiempo de tres segundos de espera. En una base de datos ocupada, este evento no se cumple jamás. Ocurre cuando el sistema está sin hacer nada durante tres segundos. En ese caso se escriben unos cuantos bloques sucios. Si la base de datos sigue desocupada los siguientes tres segundos, se escriben otros tantos bloques. Así poco a poco (mientras la base de datos siga desocupada) acabará volcando todos los búferes en disco.

[4]La aparición de un evento de checkpoint (lo que hemos denominado un checkpoint total). Esto provoca escribir absolutamente todos los bloques sucios. Es el momento de máximo trabajo en disco y, por lo tanto, el momento más crítico porque en un
checkpoint se pueden tener que grabar miles de datos. Por ello, Oracle inicialmente pone el parámetro que controla el tiempo de aparición de un checkpoint a cero (que es lo mismo que tiempo infinito).

2LGWR

Proceso de escritura de logs (LoG WriteR Process). Proceso encargado de escribir en los archivos redo log. Escribe los datos del búfer de Redo Log (en la SGA) a los archivos Redo Log en disco. Lo hace cuando:

En el buffer redo log se almacena información sobre los cambios recientes acaecidos en la base de datos. Como los datos no se escriben inmediatamente en los archivos de datos, esta información es la vital para recuperar la base de datos en caso de problemas.

Las instrucciones DML están limitadas por la velocidad de este proceso al guardar los datos. Es decir, la velocidad en grabar los datos en una base de datos Oracle, viene determinada por la velocidad de LGWR.

En caso de gran actividad de instrucciones DML entre varias sesiones, LGWR puede realizar confirmaciones en grupo para minimizar el impacto de la escritura en disco.

3CKPT

Proceso encargado de registrar la llegada de un checkpoint, momento en el que se graban búferes de datos en los archivos de datos. CKPT graba en los archivos de control la posición de checkpoint y el SCN correspondiente en los Red Log.

También graba en los archivos de datos (en la cabecera) para actualizarla con la información del punto de control y la información sobre el último SCN que se ha grabado.

Además comunica a DBW la necesidad de grabar los búferes sucios.

4SMON

System Monitor. Proceso encargado de monitorizar el sistema. Sus principales labores son:

SMON puede ser invocado por otros procesos.

5PMON

Process Monitor. Se encarga de gestionar el fallo en un proceso de usuario. Sus labores son:

6RECO

Se usa solo en bases de datos distribuidas. Resuelve los fallos ocurridos en transacciones distribuidas. Cuando detecta fallos en una transacción que tiene diferentes datos en los distintos servidores, se encarga de resolver la situación.

7MMON y MMNL

MMON es el proceso monitor de manejabilidad (manageability monitor process), encargado de realizar tareas relacionadas con el AWR, área de volcado de estadísticas de los servidores Oracle.

MMNL es el proceso ligero de monitorización de manejabilidad (manageability monitor lite process), encargado de escribir estadísticas desde el histórico de sesiones activas (ASH) en la SGA de Oracle a el disco.

Ambos son procesos necesarios para que la información estadística sobre la ejecución de Oracle esté al día.

8ARCn.

Procesos de archivado (archiver processes), encargado de escribir los archivos redo log históricos. Estos archivos son copias de los archivos Red Log. Se usan para recuperar información o para devolver la base de datos a un estado anterior.

Solo funcionan en modo ARCHIVELOG de la base de datos.

La n indica que pueden ser varios procesos (ARC0, ARC1, etc.).

9CJQ0 y Jnnn

Es el gestor de colas de trabajo (job queue processes). Los trabajos son tareas programadas por los usuarios que se pueden ejecutar varias veces.

Cada trabajo se asocia a un proceso Jnnn (por ejemplo J001).

El programador de tareas de Oracle puede invocar a CJQn cuando se necesitan ejecutar trabajos. Entonces CJQ0 lanza los procesos Jnnn de forma apropiada. Cuando finalizan los trabajos, CJQ0 se queda en estado de espera, hasta que se le vuelva a necesitar.

10FBDA

El FlashBack Data Archiver Process, es el proceso encargado de grabar la información del área de Flashback. Esta área se usa para el caso de necesitar que la base de datos regrese a un estado anterior.

[2.5] estructuras de almacenamiento en disco

[2.5.1]introducción

Una base de datos Oracle necesita los siguientes archivos para grabar la información de la misma:

Además posee (o puede poseer) estos otros archivos para que la ejecución sea correcta:

Son los archivos que almacenan los datos en sí de la base de datos. Graban la información de las tablas. Para optimizar su funcionamiento y su gestión, Oracle utiliza una estructura que relaciona la lógica de la base de datos, con la parte física.

Esta lógica interna de Oracle se describe a continuación.

1estructuras lógicas de almacenamiento de Oracle

En realidad estas estructuras forman un esquema de la base de datos que se situarían conceptualmente entre el esquema interno y el físico de la base de datos.

Oracle llama a estas estructuras Logical Storage Structures, por lo que en español se suele traducir como estructuras lógicas de almacenamiento.

1tablespaces

Los espacios de tabla o tablespaces, son una estructura lógica que, conceptualmente, se sitúa entre la lógica de la base de datos y las estructuras físicas que almacenarán los datos.

En la base de datos, se manejan objetos a nivel lógico (tablas, columnas, filas, vistas, índices,…). La información de esos objetos se tiene que almacenar en archivos de datos. Oracle crea los tablespaces como un elemento intermedio entre el nivel lógico y el nivel físico de la base de datos. Relaciona ambas ópticas para optimizar el funcionamiento del sistema.

Por defecto Oracle proporciona los siguientes espacios de tabla:

Naturalmente podemos crear otros tablespaces y asignarles los archivos de datos que deseemos.

Los tablespaces se dividen en segmentos, estos en extensiones y las extensiones en bloques.

Un tablespace puede abarcar más de un fichero de datos. Cada fichero, sin embargo, se asigna a solamente un tablespace.

2segmentos

En cada tablespace existen segmentos, que están relacionados directamente con un objeto de la base de datos (una tabla, un índice,…). Hay tres tipos de segmentos:

El mismo segmento puede estar presente en más de un archivo de datos (como en la Ilustración 22 ocurre con el segmento que almacena la tabla 3). Esta idea se usa para segmentos que almacenan datos de objetos con mucho contenido.

Para explicar, muchas veces se relaciona segmento con tabla. Pero realmente los segmentos almacenan otros objetos.

Por ejemplo esta instrucción (que crea una tabla no relaciona):

CREATE TABLE obras(titulo VARCHAR2(30));

Solo crearía un segmento para almacenar los datos de la tabla.

Sin embargo esta otra:

CREATE TABLE obras(
  id_obra NUMBER PRIMARY KEY,
  titulo VARCHAR2(30) UNIQUE,
  texto CLOB
);

Creará, al menos, estos segmentos:

3extensiones

Los segmentos se dividen en extensiones. Las extensiones son divisiones dentro del segmento que permiten asegurar que el sistema tiene reservado un conjunto de bloques contiguos en el disco. Es decir las extensiones evitan fragmentar en exceso los discos.

El funcionamiento es el siguiente: cuando hemos llenado un segmento, entonces se añade una extensión (el tamaño de las extensiones se puede calibrar) y eso significa que se amplia el segmento en el tamaño de dicha extensión. Es decir, se reserva ese espacio.

De esa forma los bloques siguientes (hasta llenar la extensión) que se añadan, tendremos la seguridad que irán contiguos en disco, disminuyendo su fragmentación.

Como es lógico, una extensión está asociada a sólo un archivo.

4bloques de datos

Es el elemento de datos más pequeño distinguible por Oracle. Cada extensión consta de una serie de bloques. El tamaño de bloque se puede configurar por parte del DBA para optimizar el rendimiento.

El tamaño del bloque de datos debe cumplir que sea múltiplo del tamaño de bloque del disco del Sistema Operativo. Es decir si en un disco concreto, el Sistema Operativo tiene un tamaño de bloque de 16KB, sólo podremos asignar tamaños de bloque de 16 KB, 32 KB, 48 KB, 64 KB etc.

En el bloque de datos de Oracle, los datos se organizan en filas. Así se asegura que cada fila se almacena junta en el bloque de datos. Además en cada bloque se graba una cabecera con información general del bloque, de la tabla a la que pertenece y de las filas que almacena.

El espacio libre del bloque está en el interior, de modo que la cabecera y la información de las tablas crecen hacia el interior del bloque (véase Ilustración 25).

2posibilidades de gestión física de los archivos de datos

Oracle puede gestionar los archivos de datos de varias formas:

Los Redo Log son dos o más archivos que sirven para almacenar las instrucciones DML que se van confirmando en la base de datos. No graban datos, sino la información necesaria para que esa instrucción se lleve a cabo.

Sirven para recuperar los datos en caso de desastre. Por ejemplo, si la base de datos ha confirmado una transacción correspondiente al número de secuencia de cambio número 9550, significará que esa secuencia estará grabada en los Red Log. Sin embargo, puede que los archivos de datos estén en la 9540. Lo cual significa que hay 10 secuencias en los Redo Log que no se han grabado en los ficheros de datos. Si ocurre un desastre en este instante y el sistema se cierra, dependemos de los Redo Log para recuperar esas secuencias.

Los redo log graban las instrucciones de transacciones confirmadas y los datos necesarios para volver a realizarlas. La información en los redo log se graba casi instantáneamente, por lo que siempre están más al día que los archivos de datos. Además, sirven como histórico de los cambios realizados en la base de datos. Lo que puede permitir retornar a la base de datos a un punto concreto.

Los ficheros Redo Log funcionan de forma circular. Cuando se llena uno, se produce un evento de tipo log switch. Si ocurre un log switch en el último archivo, se usa el primero, sobrescribiendo la información que tuviera.

El funcionamiento consiste en lo siguiente:

[1]Cuando el usuario realiza instrucciones DML o DDL, el proceso servidor graba en el Búfer Redo Log en la SGA, la información necesaria para que esa instrucción se vuelva a ejecutar, si fuera necesario.

[2]El proceso LGWR, cuando las instrucciones son definitivas (bien transacciones aceptadas o instrucciones DDL por ejemplo), copia los datos del búfer a los archivos redo log.

[3]Cuando llenamos el archivo redo log actual, se produce el evento log switch; entonces los siguientes datos pasan al siguiente archivo redo log. Con éste ocurrirá lo mismo y así sucesivamente con cada archivo del que dispongamos.

[4]En cada cambio de archivo, se genera un número de secuencia que va anotando la secuencia de redo log (lo que es lo mismo, el número de eventos log switch que han ocurrido), así podemos tener ahora el número de secuencia 12 indicando que hemos hecho 12 cambios de archivo (o sea, han ocurrido 12 eventos log switch).

[5]Cuando ya hemos ocupado todos los archivos, al terminar de llenar el último se produce el consiguiente log switch y como no hay más archivos disponibles, grabará los siguientes datos en el primer archivo sobrescribiendo los que ya existieran (y perdiendo esos datos). El número de secuencia seguirá incrementándose, no volverá a empezar de nuevo.

[6]Todo este proceso sigue continuamente

1multiplexación, grupos de redo log

Los archivos redo log suelen constituir grupos. Esto significa que el primero archivo redo log, en realidad será un grupo de archivos. Cada grupo consta de varios archivos redo log clónicos correspondientes a las mismas secuencias (es decir tendremos varios archivos idénticos con los datos de una secuencia). La idea es que, si falla uno, tengamos otra copia disponible.

Cuando se graba un dato de tipo redo, se graba secuencialmente en todos los archivos miembros del grupo de forma multiplexada. Es decir, primero en uno, luego en otro y así hasta terminar el grupo.

Es tarea del administrador determinar la configuración de los redo log (número de grupos, número de archivos, ….). Así como decidir en qué discos se almacena cada archivo miembro de cada grupo. Lo ideal, es que los miembros de cada grupo estén en discos distintos para mayor seguridad.

Además hay que tener en cuenta que la grabación de la información en los redo log debe de ser lo más rápida posible; la grabación en disco (desde el búfer) es crítica, porque durante dicha grabación la sesión queda parada hasta terminar el volcado de datos. Por ello los discos donde se almacenen redo log deben de ser muy rápidos.

Por defecto la base de datos tendrá tres grupos, pero con un solo miembro cada uno (es la situación mostrada en la Ilustración 27). Eso significa que no hay multiplexación y, por lo tanto, hay riesgo alto de perder un redo log.

[2.5.4]histórico de archivos redo log (archive redo log)

Se explicó en el apartado anterior que los archivos redo log tienen un comportamiento circular, es decir que cuando llegamos al último archivo, si se llena; entonces los siguientes datos pasan al primero, borrando la secuencia que estuviera grabada en él.

Esto no tiene que ser un problema ya que desde que se vuelve al primer archivo de la secuencia, los datos pueden estar ya grabados definitivamente en los archivos de datos mediante el proceso DBW.

Pero puede ocurrir que no sea así y esos datos no estuvieran grabados, por lo que en caso de caída del sistema les perdemos y eso sería una situación de desastre.

El registro histórico de archivo redo log (también llamado archivados redo log) evitan esta situación. Para ello la base de datos debe de estar en modo ARCHIVELOG (el modo contrario es el NOARCHIVELOG que es el habitual), si es así, entonces cada vez que ocurre un evento log switch (es decir cada vez que hay un cambio de secuencia), el proceso ARCn (la n significa que puede haber varios: ARC0, ARC1,…) graba una copia de la secuencia actual en el histórico.

Por ejemplo supongamos que tenemos tres grupos de archivos redo log y estamos en modo ARCHIVELOG:

[1]Inicialmente el proceso LGWR graba en la secuencia 1, suponemos que está secuencia se graba en el grupo 1 de archivos redo log (hay que recordar que un grupo de redo log puede estar formado por varios archivos clónicos redo log)

[2]Cuando la secuencia 1 se llena, pasamos a la secuencia 2 (se produce un log switch) y entonces el proceso ARC graba una copia de la secuencia 1 en el directorio de los históricos redo log (cuya ruta se puede configurar).

[3]Cuando la secuencia 2 se llena, entonces se copia esa secuencia en el histórico y pasaremos a la secuencia 3

[4]Cuando la secuencia 3 se llena, LGWR empezará a sobreescribir el grupo redo log que tenía la secuencia 1. El proceso ARC grabará una copia de la secuencia 3.

[5]Entonces se empezará a grabar los siguientes redo log en el grupo 1, sobrescribiendo la información anterior. Pero no pasa nada porque tenemos copia de todas las secuencias, incluida la 1.

Evidentemente el problema de esta forma de trabajar es el espacio que necesitamos. Además obligamos a Oracle a usar cada vez más los discos, con más procesos funcionando que requieren grabación en ellos. A cambio aseguramos que no perderemos información.

Incluso podemos multiplexar cada archivo del histórico para tener, no ya una copia, sino varias de cada secuencia, con lo que la seguridad es aún mayor.

[2.5.5]archivos de control

Se trata de archivos binarios y de tamaño pequeño que contienen la estructura de la base de datos, es decir metadatos. Este archivo también se puede multiplexar para aumentar la seguridad, con lo que puede haber varios. Lo normal es tener al menos dos, ya que es un recurso crítico.

Los archivos de control contienen:

1archivos de parámetros

Contienen los parámetros generales de configuración de la base de datos. Los parámetros son el conjunto de una clave y un valor. Por ejemplo el parámetro con clave SGA_MAX_SIZE tendría como valor el tamaño máximo que podremos tener de SGA.

Hay dos tipos de archivos de parámetros:

Lo aconsejable es usar el formato SPFILE pero tener al menos una copia en formato PFILE.

Los parámetros sirven para cambiar y conocer la configuración de Oracle. Cada parámetro refleja un aspecto del funcionamiento de Oracle; modificándole, modificaremos el comportamiento de la instancia de Oracle.

2archivos de contraseñas

Contienen la lista de contraseñas cifradas de los usuarios administradores. Son imprescindibles para que los usuarios de tipo DBA puedan conectar con la base de datos. En caso de pérdida no se podrá validar a los usuarios administradores, por lo que se conservación es crítica.

3archivos de traza

Son archivos de texto que permiten establecer el seguimiento del funcionamiento de la base de datos. Gracias a ellos podremos saber las acciones llevadas a cabo por muchos procesos importantes de Oracle (como PMON y SMON por ejemplo) y así detectar problemas o cuellos de botella en el rendimiento.

El número y funcionamiento de cada archivo de traza se puede configurar para realizar el seguimiento deseada al funcionamiento de la base de datos..

4archivo de alerta (alert log)

Es, en cierto modo, un archivo de traza pero que sirve para almacenar información sobre el funcionamiento de Oracle. Es el diario de Oracle, graba todas las cosas importantes acaecidas (cuando se inició la instancia, cada aparición de checkpoint, los eventos log switch,…).

Es un archivo de texto que se crea cuando la base de datos se lanza por primera vez y continuamente almacena lo que ocurre en ella.

5archivos de copia de seguridad

Imprescindibles para la recuperación de la base de datos en caso de desastre.

6archivos temporales

Son un tipo especial de archivo de datos que sirve para almacenar datos que proceden de operaciones que mueven tanta información que no cabe en la memoria y se necesita cachear en disco. Contienen datos intermedios necesarios para ejecutar algunas instrucciones. Cuando las instrucciones finalizan, se van borrando esos datos.

7log de operaciones flashback

Oracle tiene la posibilidad de retornar la base de datos a un momento concreto de tiempo. Es un volver al pasado que permite anular una situación grave de pérdida de datos. Para ello se debe configurar Oracle con posibilidad de usar un área de flashback.

El archivo log para flashback contiene información necesaria para poder devolver la base de datos a un estado anterior en el tiempo. Es decir, son fundamentales para que una operación de tipo flashback pueda funcionar.

8archivos DMP

Se utilizan para realizar operaciones de exportación e importación de datos. Contienen información independiente de la plataforma que permite realizar exitosamente la operación de exportación e importación. La información que contienen es binaria.