¿Qué es un PGA de Oracle?

PGA (Área Global de Programa) es un área de memoria utilizada por un proceso Oracle. Esta zona de memoria no se puede compartir, es decir es la memoria privada de cada proceso servidor. En esta memoria cada proceso almacena información que sólo es necesaria para su propio funcionamiento.

La PGA se compone de:

- Área SQL privada: 

Cada SQL que se ejecuta necesita de este espacio para poder llevar el control de las operaciones propias de la sentencia. Se asigna cuando se abre el cursor y se libera completamente cuando se cierra. Esta parte de memoria se subdivide en dos:

* Área persistente: 

Perdura durante toda la vida del cursor. Guarda las bind variables además de otras cosas.

* Área en tiempo de ejecución: 

Se libera cuando finaliza la ejecución de la sentencia SQL (aunque no se haya cerrado el cursor ). Constituyen las áreas de trabajo (working areas). El número máximo de cursores, y por tanto, el número máximo de áreas SQL privadas, que un usuario puede tener abiertos al mismo tiempo se controla con el parámetro OPEN_CURSORS. 

También hay que tener en cuenta que esta área SQL privada se almacena en la PGA si la Instancia está configurada como servidores dedicados (dedicated servers).

En caso de servidors compartidos (shared servers) se almacena en la SGA.

- Memoria de las sesiones: 

Guarda información relativa a la sesión como el login, variables de sesión... etc. En servidores compartidos (shared servers) este área pasa a ser pública ya que diferentes usuarios comparten los mismos procesos servidores.

¿Qué es un SGA de Oracle?

SGA (Área Global del Sistema) es una estructura básica de memoria de Oracle que sirve para facilitar la transferencia de información entre usuarios y también almacena la información estructural de la BD más frecuentemente requerida.

El área global del sistema y un conjunto de procesos de la base de datos constituyen una instancia de una base de datos Oracle. La base de datos Oracle automáticamente reserva memoria para el área global del sistema cuando se inicia una instancia, y el sistema operativo reclama la memoria cuando se apaga dicha instancia. Cada instancia tiene su propia SGA.

Está compuesto por:

- Database Buffer Cache (Buffers de BD)

Es el caché que almacena los bloques de datos leidos de los segmentos de datos de la BD, tales como tablas, índices y clusters. Los bloques modificados se llamas bloques sucios. El tamaño de buffer caché se fija por el parámetro DB_BLOCK_BUFFERS.

- Buffer Redo Log

Los registros Redo describen los cámbios realizados en la BD y son escritos en los ficheros redo log para que puedan ser utilizados en las operaciones de recuperación hacia adelante, roll-forward, durante las recuperaciones de la BD. Pero antes de ser escritos en los ficheros redo log son escritos en un caché de la SGA llamado redo log buffer. El servidor escribe periódicamente los registrosredo log en los ficheros redo log. El tamaño del buffer redo log se fija por el parámetro LOG_BUFFER.

- Shared SQL Pool (Área de SQL Compartido, )

En esta zona se encuentran las sentencias SQL que han sido analizadas. El analisis sintáctico de las sentencias SQL lleva su tiempo y Oracle mantiene las estructuras asociadas a cada sentencia SQL analizada durante el tiempo que pueda para ver si puede reutilizarlas. Antes de analizar una sentencia SQL, Oracle mira a ver si encuentra otra sentencia exactamente igual en la zona de SQL compartido. Si es así, no la analiza y pasa directamente a ejecutar la que mantinene en memoria. El tamaño del caché está gestionado internamente por el servidor, pero es parte del shared pool, cuyo tamaño viene determinado por el parámetro SHARED_POOL_SIZE.

¿Cuáles son los roles de un DBA?

El rol general del DBA es facilitar el desarrollo y el uso de la Base de Datos dentro de las guías de acción definidas por la Administración de los Datos.

El DBA es responsable primordialmente de:

- Administrar la estructura de la Base de Datos

La administración de la estructura de la Base de Datos incluye participar en el diseño inicial de la misma y  su puesta en practica así como controlar, y administrar sus requerimientos, ayudando a evaluar alternativas, incluyendo los DBMS a utilizar y ayudando en el diseño general de BD.

- Administrar la actividad de los datos

Aunque el DBA protege los datos, no los procesa. El DBA no es usuario del sistema, en consecuencia, no administra valores de datos; el DBA administra actividad de datos. Dado que la BD es un recurso compartido, el DBA debe proporcionar estándares, guías de acción, procedimientos de control y la documentación necesaria para garantizar que los usuarios trabajan en forma cooperativa y complementaria al procesar datos en la BD.

- Administrar el Sistema Manejador de Base de Datos

Deberá compilar y analizar estadísticas relativas al rendimiento del sistema e identificar áreas potenciales del problema. Dado que la BD esta sirviendo a muchos grupos de usuarios, el DBA requiere investigar todas las quejas sobre el tiempo de respuesta del sistema, la precisión de los datos, la facilidad de uso, vigilar periódica y continuamente las actividades de los usuarios en la BD, administrar y controlar la migración tanto de las estructuras, como de los datos y las aplicaciones. Si se requieren cambios el DBA deberá planearlos y ponerlos en practica.

- Mantener la integridad de los datos

Se encarga de asegurar que las operaciones ejecutadas por los usuarios sean correctas y mantengan la consistencia. También debe protegerse de fallos de hardware o software.

- Mantener la seguridad de los datos

Proteger del uso mal intencionado o no autorizados así como limitar a los usuarios a ejecutar únicamente las operaciones permitidas.

- Mantener la disponibilidad de los datos

Procedimientos de recuperación de la base de datos en caso de fallos de hardware o software.

Describa cada proceso de background de Oracle

Un proceso de background es creado para cada instancia de Oracle, realizan la entrada/salida de una manera asíncrona y proporcionan paralelismo para mejor rendimiento y fiabilidad.

Los procesos son:

DBWR: Este proceso es el que se encarga de escribir a disco. Es el único con permiso de escritura en disco, o sea en la base de datos. Cuando nosotros escribimos, hacemos un commit en la base de datos, realmente no está escribiendo en disco, si no que está marcando una serie de bloques de datos como que son susceptibles de ser escritos en disco, es decir, marca los datos como "confirmados", pero no escribe, si no que espera a que otra transaccion los requiera para llevarlos a disco y así ahorrar un "viaje" o una operación. Por eso mismo cuando la base de datos cae..o la paramos con la opcion "abort", queda inconsistente, ya que puede tener datos en bufferes "confirmados" que realmente no están escritos en disco. Por eso cuando volvemos a arrancar, necesita realizar una recuperación.

LGWR: Este proceso es que se encarga de escribir el contenido del búfer del registro de rehacer en los ficheros de registro de rehacer en linea. Se realizan las escrituras por lotes. El buffer del registro de rehacer(redo log), contiene siempre el estado más reciente de la base de datos, ya que es posible que el proceso DBWR espere antes de escribir los bloques modificados desde los búferes de bloques de datos a los archivos de datos. Los archivos de registro de rehacer son ficheros secuenciales lo que indica que cuando acaba de escribir en uno, empieza por otro y así sucesivamente.

CKPT: Este proceso es el encargado de realizar un "punto de comprobacion". Cuando se sucede un punto de comprobacion, CKPT hace que DBWR escriba todos los bloques que se hayan modificado desde el último punto de comprobación, y actualize los archivos de control y las cabeceras de los archivos de datos para registrar el punto de comprobación. Los puntos de comprobacion de producen de forma automática cuando se llena un archivo de registro de rehacer en linea.

Se puede configurar el checkpoint en el fichero de inicializacion de parametros con el parametro: LOG_CHEKPOINT_INTERVAL.

SMON: Este proceso realiza la recuperación de la instancia, segun sea preciso usando los registros de rehacer en línea... (antes hablamos de que si oracle se para necesitaría hacer una recuperacion si se para anormalmente, pues lo realiza así). Limpia la base de datos de transacciones inservibles. Tambien cumple la función de agrupar extensiones libres contiguas en la base de datos. Smon solo agrupa el espacio libre en espacios de tablas cuyo valor de almacenamiento predeterminado sea distinto de 0.

PMON: Realiza limpiezas de procesos fallidos de usuarios. Libera recursos que estuviera usando el usuario. Sirve por ejemplo cuando hay bloqueos. libera bloqueos y pone a disposición para otros usuarios.

ARCH: Proceso que escribe en los registros de rehacer en linea de forma ciclica, es decir, despues de llenar el primero, va al segundo, cuando lo llena, va al tercero y asi sucesivamente. Una vez terminado el último fichero de rehace en linea, LGWR empieza a sobreescribir los contenidos del primero. Cuando la base de datos se ejecuta en modo ARCHIVELOG, ARCH realiza una copia del cada uno de ficheros de rechace en linea antes de ser sobreescrito.

RECO: Este proceso es el encargado de realizar las recuperaciones de fallos en las bases de datos distribuidas. Este proceso trata de acceder a las bases de datos implicadas en transacciones distribuidas dudas e intenta resolver las transacciones.