El administrador de base de datos (DBA) es la persona responsable de los aspectos ambientales de una base de datos. En general esto incluye:
*Recuperabilidad - Crear y probar Respaldos
*Integridad - Verificar o ayudar a la verificación en la integridad de datos
*Seguridad - Definir y/o implementar controles de acceso a los datos
*Disponibilidad - Asegurarse del mayor tiempo de encendido
*Desempeño - Asegurarse del máximo desempeño incluso con las limitaciones
*Desarrollo y soporte a pruebas - Ayudar a los programadores e ingenieros a utilizar eficientemente la base de datos.
viernes, 21 de agosto de 2009
¿Que es una instancia Oracle?
La instancia es la unión de los Procesos y de las Estructuras de Memoria, los cuales se hallan en ejecución para el acceso de los usuarios a los datos a través de diferentes aplicaciones como por ejemplo administración, desarrollo y otras aplicaciones de usuario final.
Está conformada por las siguientes Procesos:
Procesos usuario
Procesos servidores
Procesos de fondo:
*PMON (Monitor de procesos)
*SMON (Monitor del sistema)
*DBWR (Proceso de escritura)
*LGWR (Proceso de registro de operaciones)
*CKPT (Proceso de Checkpoint)
Está conformada por las siguientes estructuras de memoria:
SGA (System Global Area)
Area compartida (Shared pool):El shared pool se encuentra dividido en dos areas e memoria llamadas (en ingles) data dictionary cache y library cache
Database buffer cache
Redo log buffer
Large pool
Java pool
Está conformada por las siguientes Procesos:
Procesos usuario
Procesos servidores
Procesos de fondo:
*PMON (Monitor de procesos)
*SMON (Monitor del sistema)
*DBWR (Proceso de escritura)
*LGWR (Proceso de registro de operaciones)
*CKPT (Proceso de Checkpoint)
Está conformada por las siguientes estructuras de memoria:
SGA (System Global Area)
Area compartida (Shared pool):El shared pool se encuentra dividido en dos areas e memoria llamadas (en ingles) data dictionary cache y library cache
Database buffer cache
Redo log buffer
Large pool
Java pool
¿Que es el SGA - Oracle?
El SGA (System Global Area o también Shared Global Area)es la zona de memoria en la que la BD Oracle guarda información sobre su estado. Esta estructura de memoria está disponible para todos los procesos, por eso se dice que está compartida. 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.
La SGA se divide en varias partes:
Buffers de BD, Database Buffer Cache
Buffer Redo Log
Área de SQL Compartido, Shared SQL Pool
La SGA se divide en varias partes:
Buffers de BD, Database Buffer Cache
Buffer Redo Log
Área de SQL Compartido, Shared SQL Pool
¿Ques es el PGA - Oracle?
El PGA (Program Global Area) es la zona de memoria de cada proceso Oracle. No está compartida y contiene datos e información de control de un único proceso.
Concepto de cada Proceso Background (SMON, PMON, DBWR, LGWR, CKPT, ARCH, RECO, LCK)
SMON (System Monitor): Es el supervisor del sistema y se encarga de todas las recuperaciones que sean necesarias durante el arranque. Esto puede ser necesario si la BD se paró inesperadamente por fallo físico, lógico u otras causas. Este proceso realiza la recuperación de la instancia de BD a partir de los ficheros redo log. Además límpia los segmentos temporales no utilizados y compacta los huecos libres contiguos en los ficheros de datos. Este proceso se despierta regularmente para comprobar si debe intervenir.
PMON (Process Monitor): Este proceso restaura las transacciones no validadas de los procesos de usuario que abortan, liberando los bloqueos y los recursos de la SGA. Asume la identidad del usuario que ha fallado, liberando todos los recursos de la BD que estuviera utilizando, y anula la transacción cancelada. Este proceso se despierta regularmente para comprobar si su intervención es necesaria.
DBWR(Database Writer): Es el responsable de gestionar el contenido de los buffers de datos y del caché del diccionario. Él lee los bloques de los ficheros de datos y los almacena en la SGA. Luego escribe en los ficheros de datos los bloques cuyo contenido ha variado. La escritura de los bloques a disco es diferida buscando mejorar la eficiencia de la E/S.
Es el único proceso que puede escribir en la BD. Esto asegura la integridad. Se encarga de escribir los bloques de datos modificados por las transacciones, tomando la información del buffer de la BD cuando se valida una transacción. Cada validación no se lleva a la BD física de manera inmediata sino que los bloques de la BD modificados se vuelcan a los ficheros de datos periodicamente o cuando sucede algún checkpoint o punto de sincronizaión: grabación diferida:
* Los bloques del buffer de la BD (bloques del segmento de rollback y bloques de datos) menos recientemente utilizados son volcados en el disco continuamente para dejar sitio a los nuevos bloques.
* El bloque del segmento de rollback se escribe SIEMPRE antes que el correspondiente bloque de datos.
* Múltiples transacciones pueden solapar los cambios en un sólo bloque antes de escribirlo en el disco.
Mientras, para que se mantenga la integridad y coherencia de la BD, todas las operaciones se guardan en los ficheros de redo log. El proceso de escritura es asíncrono y puede realizar grabaciones multibloque para aumentar la velocidad.
LGWR (Log Writer): Es el encargado de escribir los registros redo log en los ficheros redo log. Los registros redo log siempre contienen el estado más reciente de la BD, ya que puede que el DBWR deba esperar para escribir los bloques modificados desde el buffer de datos a los ficheros de datos.
Conviene tener en cuenta que el LGWR es el único proceso que escribe en los ficheros de redo log y el único que lee directamente los buffers de redo log durante el funcionamiento normal de la BD.
Coloca la información de los redo log buffers en los ficheros de redo log. Los redo log buffers almacenan una copia de las transacciones que se llevan a cabo en la BD. Esto se produce:
* a cada validación de transacción, y antes de que se comunique al proceso que todo ha ido bien,
* cuando se llena el grupo de buffers de redo log
* cuando el DBWR escribe buffers de datos modificados en disco.
Así, aunque los ficheros de DB no se actualicen en ese instante con los buffers de BD, la operación queda guardada y se puede reproducir. Oracle no tiene que consumir sus recursos escribiendo el resultado de las modificaciones de los datos en los archivos de datos de manera inmediata. Esto se hace porque los registros de redo log casi siempre tendrán un tamaño menor que los bloques afectados por las modificaciones de una transacción, y por lo tanto el tiempo que emplea en guardarlos es menor que el que emplearía en almacenar los bloques sucios resultado de una transacción; que ya serán trasladados a los ficheros por el DBWR. El LGWR es un proceso único, para asegurar la integridad. Es asíncrono. Además permite las grabaciones multibloque.
CKPT (Checkpoint): Este proceso escribe en los ficheros de control los checkpoints. Estos puntos de sincronización son referencias al estado coherente de todos los ficheros de la BD en un instante determinado, en un punto de sincronización. Esto significa que los bloques sucios de la BD se vuelcan a los ficheros de BD, asegurándose de que todos los bloques de datos modificados desde el último checkpoint se escriben realmente en los ficheros de datos y no sólo en los ficheros redo log; y que los ficheros de redo log también almacenan los registros de redo log hasta este instante. La secuencia de puntos de control se almacena en los ficheros de datos, redo log y control. Los checkpoints se produce cuando:
* un espacio de tabla se pone inactivo, offline,
* se llena el fichero de redo log activo,
* se para la BD,
* el número de bloques escritos en el redo log desde el último checkpoint alcanza el límite definido en el parámetro LOG_CHECKPOINT_INTERVAL,
* cuando transcurra el número de segundos indicado por el parámetro LOG_CHECKPOINT_TIMEOUT desde el último checkpoint.
Está activo si el parámetro CHECKPOINT_PROCESS tiene un valor verdadero.
ARCH (Archiver): El proceso archivador tiene que ver con los ficheros redo log. Por defecto, estos ficheros se reutilizan de manera cíclica de modo que se van perdiendo los registros redo log que tienen una cierta antiguedad. Cuando la BD se ejecuta en modo ARCHIVELOG, antes de reutilizar un fichero redo log realiza una copia del mismo. De esta manera se mantiene una copia de todos los registros redo log por si fueran necesarios para una recuperación. Este es el trabajo del proceso archivador.
RECO (Recoverer): El proceso de recuperación está asociado al servidor distribuido. En un servidor distribuido los datos se encuentran repartidos en varias localizaciones físicas, y estas se han de mantener sincronizadas. Cuando una transacción distribuida se lleva a cabo puede que problemas en la red de comunicación haga que una de las localizaciones no aplique las modificaciones debidas. Esta transacción dudosa debe ser resuelta de algún modo, y esa es la tarea del proceso recuperador. Está activo si el parámetro DISTRIBUTED_TRANSACTIONS tiene un valor distinto de 0.
LCK (Lock): El proceso de bloqueo está asociado al servidor en paralelo.
PMON (Process Monitor): Este proceso restaura las transacciones no validadas de los procesos de usuario que abortan, liberando los bloqueos y los recursos de la SGA. Asume la identidad del usuario que ha fallado, liberando todos los recursos de la BD que estuviera utilizando, y anula la transacción cancelada. Este proceso se despierta regularmente para comprobar si su intervención es necesaria.
DBWR(Database Writer): Es el responsable de gestionar el contenido de los buffers de datos y del caché del diccionario. Él lee los bloques de los ficheros de datos y los almacena en la SGA. Luego escribe en los ficheros de datos los bloques cuyo contenido ha variado. La escritura de los bloques a disco es diferida buscando mejorar la eficiencia de la E/S.
Es el único proceso que puede escribir en la BD. Esto asegura la integridad. Se encarga de escribir los bloques de datos modificados por las transacciones, tomando la información del buffer de la BD cuando se valida una transacción. Cada validación no se lleva a la BD física de manera inmediata sino que los bloques de la BD modificados se vuelcan a los ficheros de datos periodicamente o cuando sucede algún checkpoint o punto de sincronizaión: grabación diferida:
* Los bloques del buffer de la BD (bloques del segmento de rollback y bloques de datos) menos recientemente utilizados son volcados en el disco continuamente para dejar sitio a los nuevos bloques.
* El bloque del segmento de rollback se escribe SIEMPRE antes que el correspondiente bloque de datos.
* Múltiples transacciones pueden solapar los cambios en un sólo bloque antes de escribirlo en el disco.
Mientras, para que se mantenga la integridad y coherencia de la BD, todas las operaciones se guardan en los ficheros de redo log. El proceso de escritura es asíncrono y puede realizar grabaciones multibloque para aumentar la velocidad.
LGWR (Log Writer): Es el encargado de escribir los registros redo log en los ficheros redo log. Los registros redo log siempre contienen el estado más reciente de la BD, ya que puede que el DBWR deba esperar para escribir los bloques modificados desde el buffer de datos a los ficheros de datos.
Conviene tener en cuenta que el LGWR es el único proceso que escribe en los ficheros de redo log y el único que lee directamente los buffers de redo log durante el funcionamiento normal de la BD.
Coloca la información de los redo log buffers en los ficheros de redo log. Los redo log buffers almacenan una copia de las transacciones que se llevan a cabo en la BD. Esto se produce:
* a cada validación de transacción, y antes de que se comunique al proceso que todo ha ido bien,
* cuando se llena el grupo de buffers de redo log
* cuando el DBWR escribe buffers de datos modificados en disco.
Así, aunque los ficheros de DB no se actualicen en ese instante con los buffers de BD, la operación queda guardada y se puede reproducir. Oracle no tiene que consumir sus recursos escribiendo el resultado de las modificaciones de los datos en los archivos de datos de manera inmediata. Esto se hace porque los registros de redo log casi siempre tendrán un tamaño menor que los bloques afectados por las modificaciones de una transacción, y por lo tanto el tiempo que emplea en guardarlos es menor que el que emplearía en almacenar los bloques sucios resultado de una transacción; que ya serán trasladados a los ficheros por el DBWR. El LGWR es un proceso único, para asegurar la integridad. Es asíncrono. Además permite las grabaciones multibloque.
CKPT (Checkpoint): Este proceso escribe en los ficheros de control los checkpoints. Estos puntos de sincronización son referencias al estado coherente de todos los ficheros de la BD en un instante determinado, en un punto de sincronización. Esto significa que los bloques sucios de la BD se vuelcan a los ficheros de BD, asegurándose de que todos los bloques de datos modificados desde el último checkpoint se escriben realmente en los ficheros de datos y no sólo en los ficheros redo log; y que los ficheros de redo log también almacenan los registros de redo log hasta este instante. La secuencia de puntos de control se almacena en los ficheros de datos, redo log y control. Los checkpoints se produce cuando:
* un espacio de tabla se pone inactivo, offline,
* se llena el fichero de redo log activo,
* se para la BD,
* el número de bloques escritos en el redo log desde el último checkpoint alcanza el límite definido en el parámetro LOG_CHECKPOINT_INTERVAL,
* cuando transcurra el número de segundos indicado por el parámetro LOG_CHECKPOINT_TIMEOUT desde el último checkpoint.
Está activo si el parámetro CHECKPOINT_PROCESS tiene un valor verdadero.
ARCH (Archiver): El proceso archivador tiene que ver con los ficheros redo log. Por defecto, estos ficheros se reutilizan de manera cíclica de modo que se van perdiendo los registros redo log que tienen una cierta antiguedad. Cuando la BD se ejecuta en modo ARCHIVELOG, antes de reutilizar un fichero redo log realiza una copia del mismo. De esta manera se mantiene una copia de todos los registros redo log por si fueran necesarios para una recuperación. Este es el trabajo del proceso archivador.
RECO (Recoverer): El proceso de recuperación está asociado al servidor distribuido. En un servidor distribuido los datos se encuentran repartidos en varias localizaciones físicas, y estas se han de mantener sincronizadas. Cuando una transacción distribuida se lleva a cabo puede que problemas en la red de comunicación haga que una de las localizaciones no aplique las modificaciones debidas. Esta transacción dudosa debe ser resuelta de algún modo, y esa es la tarea del proceso recuperador. Está activo si el parámetro DISTRIBUTED_TRANSACTIONS tiene un valor distinto de 0.
LCK (Lock): El proceso de bloqueo está asociado al servidor en paralelo.
Suscribirse a:
Entradas (Atom)