Otras existen solo si ciertas opciones han
sido habilitadas, este último grupo incluye los procesos requeridos para RAC y
Streams. Adicionalmente, existen algunos procesos que no están debidamente
documentados. Hay una variación de plataforma que debe ser aclarado antes de
discutir los procesos. Sobre Linux y Unix, todos los procesos Oracle son
procesos separados del sistema operativo, cada uno con un número de proceso
único. Sobre Windows, hay un solo proceso del Sistema Operativo (llamado
ORACLE.EXE) para toda la instancia: los procesos Oracle se ejecutan como hilos
separados dentro de este proceso.
SMON, EL SYSTEM MONITOR.
SMON tiene inicialmente la tarea del
montaje y de abrir una Base de Datos, los pasos involucrados en esto son
descritos en detalle en el Capitulo 5. En resumen, SMON monta una Base de Datos
localizando y validando el Database ControlFile (ControlFile de la Base de
Datos). Y luego abre una Base de Datos localizando y validando todos los
DataFiles y Online Log Files. Una vez que la Base de Datos es Abierta y en uso,
SMON es responsable de varias tareas de mantenimiento, tales como recopilación
de espacio libre en DataFiles.
PMON, EL PROCESS MONITOR.
Una sesión de usuario es un Proceso de
Usuario que está conectado a un Proceso Servidor. El proceso servidor es
lanzado cuando la sesión es creada y destruido cuando la sesión es finalizada.
Una salida ordenada de una sesión implica que el usuario cierra la sesión.
Cuando esto ocurre, cualquier trabajo que estaba haciendo se completará de
manera ordenada, y el proceso servidor será terminado. Si la sesión es
terminada de una manera desordenada (quizás porque la PC es reiniciada),
entonces la sesión será dejada en un estado que debe ser aclarado. PMON
monitorea todos los procesos de servidor y detecta cualquier problema con las
sesiones. Si una sesión es terminada anormalmente, PMON destruirá los procesos
servidor, regresa su memoria PGA al Pool de memoria libre del Sistema
operativo, y regresar cualquier transacción incompleta que puede haber estado
en progreso.
EXAMEN.
Si una sesión es terminada anormalmente,
que sucederá a una transacción activa? Será regresado (Roll Back) , por el
proceso Background PMON.
DBWn, EL DATABASE WRITER.
Recuerde siempre que las sesiones como
regla general no escriben a disco. Ellas escriben los datos a los búferes en el
Database Buffer Cache. Es el Database Write que posteriormente escribe los
búferes a Disco. Es posible para una instancia tener varios Database Writer
(hasta un máximo de veinte (20)), que se llamarán DBW0, DBW1, y así en
adelante: Por lo tanto el uso del término DBWn para referir al Database Write.
El número predeterminado es un Database Writer por ocho CPU, reunidos.
EN EL TRABAJO.
Cuantos Database Writers usted necesita?
El número predeterminado puede ser correcto. Agregar más puede ayudar al
rendimiento, pero por lo general usted debería buscar ajustar primero la
memoria. Como una regla, antes de que usted optimice la I/O en disco, preguntar
porque existe alguna necesidad de disco I/O.
DBWn escribe Dirty Buffer (buffers sucios)
Del Database Buffer Cache a los DataFiles-pero no escribe los buffers cuando se
ensucien. Por el contrario: escribe buffers como pocos, Como se puede llegar
lejos. La idea general es que la entrada-salida del disco es mala para el
rendimiento, así que no hacerlo menos que realmente es necesario. Si un bloque
en un Buffer ha sido escrito por una sesión, hay una posibilidad razonable que
será escrito otra vez por esa sesión, u otra. ¿Por qué escribir el Buffer al
Disco, si bien pueden ser ensuciados de nuevo en un futuro? El algoritmo
utiliza DBwn para seleccionar dirty buffers para escribir a disco (cuál los
limpiará) seleccionará solamente los buffers que no han sido usados
recientemente. Así que si un buffer está muy ocupado, porque las sesiones son
varias veces la lectura o escritura, DBWn no lo escribirá a disco. Podría haber
cientos o miles de escrituras a un buffer antes de que DBWn lo limpie. Podría
ser que un Buffer Cache de un millón de buffers, cientos miles de ellos son
sucios-pero DBWn sólo podría escribir unos cuantos cientos de ellos en el disco
a la vez. Estos serán los pocos cientos que ninguna sesión se ha interesado por
algún tiempo.
EXAMEN.
¿Qué hará a DBRw a escribir? No hay
Buffers Libres, buffers Demas sucios, tiempos de esperas de 3 segundos o un
Checkpoint.
DBWn escribe según un algoritmo muy
perezoso: lo menos posible, tan raramente como sea posible. Hay cuatro
circunstancias que causarán a DBWn a escribir: No hay Buffers libres, buffers
demás sucios, tiempos de esperas de 3 segundos y cuando hay un check point.
Primero, cuando no hay Buffers libres. Si
un proceso servidor necesita para copiar un Block en el Database Buffer Cache,
este debe encontrar un Buffer Libre. Un Buffer libre es un Buffer que no es ni
sucio (actualizado, y que aun no vuelven a escribir a disco) ni fijado-cubierto
(Un Buffer Fijado es uno que está siendo utilizado por otra sesión ese mismo
momento). Un Buffer sucio no debe ser sobrescrito porque si fuera cambiado, los
datos se perderían, y un Buffer fijado no puede ser sobrescrito porque los
mecanismos del sistema operativo de protección de memoria no se permiten. Si un
proceso servidor toma demasiado tiempo (Que es demasiado tiempo-largo. Esto es
determinado internamente por Oracle) para encontrar un Buffer libre, señala el
DBWn para escribir algunos Buffer Sucios a disco. Una vez hecho esto, serán
limpios-por lo tanto libre, y disponible para su uso.
Segundo, puede haber demasiados Buffers
sucios-“Demasiados” siendo otro umbral interno. Ningún proceso de servidor pudo
haber tenido un problema el encontrar un Buffer Libre, pero total, podría haber
una gran cantidad de Buffer sucios: esto hará que DBWn para escribir algunos de
ellos a disco.
Tercero, hay tres-segundos de tiempo de
espera: cada tres segundos, DBWn limpiará algunos Buffers. En la práctica, este
evento puede no ser significativo en un sistema de producción porque las dos
circunstancias previas descritas forzarán a escribir, pero el tiempo de espera
incluso si el sistema está inactivo. En Database Buffer Cache eventualmente
será limpiado.
Cuarto, puede haber un Checkpoint
solicitado-requerido. Las tres razones ya dadas harán al DBWn escribir un
número limitado de Buffers sucios a los DataFiles. Cuando ocurre un CheckPoint,
todos los Buffer sucios son escritos. Esto podría significar cientos de miles
de ellos. Durante un CheckPoint, las entrada salidas a disco llegaran a tope,
el uso del CPU puede irse al 100%, sesiones de usuario final experimentarán una
degradación de rendimiento, y la gente empezará a quejarse. Entonces cual el
CheckPoint se ha completado (que puede tomar varios minutos) el rendimiento
regresara a normal. Asi porque tener CheckPoints? La respuesta corta es, no los
tiene a menos que usted tenga que.
EXAMEN
Que hace DBWn cuando una transacción es
confirmada-commit? No hace absolutamente nada.
El único momento cuando un CheckPoint es
absolutamente necesario es cuando la Base de Datos está cerrada y la instancia
es apagada. Una secuencia de CheckPoint en el Capitulo 5. Un CheckPoint escribe
todos los Buffers Sucios a disco: esto sincroniza el Buffer Cache con los
DataFiles, la instancia con la Base de Datos. En ejecución normal, los
DataFiles están siempre fuera de fecha: pueden ser cambios que faltan
(committed y un committed). Esto no importa, porque las copias de los Block en
el Buffer Cache esta a la fecha, y es estos en las cuales las sesiones
trabajan. Pero en un Shutdown, es necesario escribir todo a disco. CheckPoint
Automático solo se producen en el Shutdown. Pero un CheckPoint puede ser
forzado en cualquier momento con esta declaración:
alter system checkpoint;
Observe que desde la versión 8i en
adelante, los CheckPoint no ocurren en el Log Switch. El CheckPoint descrito
hasta ahora es un CheckPoint Full. CheckPoint Parciales que forzar a escribir
todos los Buffer Sucios que contienen Block apenas de uno o más DataFiles en
vez de la Base de Datos completa, ocurren con mucho más frecuencia: cuando un
DataFile o un Tablespace se toma fuera de línea; cuando un Tablespace se pone
en modo Backup; cuando un Tablespace es hecho Read-Only. Estos son menos
drásticos que un CheckPoint Full, y ocurren automáticamente siempre que suceda
el acontecimiento relevante.
Para concluir, El DBWn escribe en un
algoritmo muy perezoso: lo menos posible, tan raramente como sea
posible-excepto cuando un CheckPoint ocurre, cuando todos los Buffer sucios son
escritos a disco, lo más rápido posible.
LGWR, EL LOG WRITER.
El LGWR escribe el contenido del Log
Buffer a los Online Log Files en disco. Una escritura del Log Buffer a los
Online Redo Log Files es a menudo referida como vaciar (limpiar) el Log Buffer.
Cuando una sesión realiza cualquier cambio (INSERT, UPDATE o DELETE) a los
Blocks en el Database Buffer Cache, antes de aplicar el cambio en el Block este
escribe el Change Vector que está cerca de aplicarse al Log Buffer. Para no
perder ningún trabajo, estos Change Vectors deben ser escritos a disco con el
mínimo tiempo de retardo. Con este fin, el LGWR vuelca el contenido del Log
Buffer a los Online Redo Log Files en disco en casi tiempo real. Y cuando una
sesión emite un COMMIT, el LGWR escribe en tiempo real: La sesión se bloquea,
mientras LGWR escribe el Buffer a Disco. Solo hasta entonces la transacción
guardada es Confirmada (commited), y por lo tanto no reversible.
LGWR es uno de los últimos cuellos de
botella en la Arquitectura Oracle. Es imposible hacer DML más rápidas que LGWR
pueda escribir los Change Vectors a disco. Hay tres circunstancias que causaran
a LGWR vaciar (volcar) el Log Buffer: si una sesión emite un COMMIT, si el Log
Buffer esta a una tercera parte de lleno; si DBWn esta apunto de escribir
Buffer sucios.
Primero, Escribir un Commit. Para procesar
un COMMIT, el proceso servidor inserta un registro confirmado (commit record)
en el Log Buffer. Y a continuación se bloqueará, mientras LGWR vacía el Log
Buffer a Disco. Solo cuando esta escritura se ha completado un mensaje de Commit-complete
es regresado a la sesión. Y el proceso servidor puede continuar trabajando.
Esta es la garantía que las transacciones nunca se perderán: cada Change Vector
para una transacción confirmada (transaction committed) estará disponible en el
Redo Log en disco y por lo tanto ser aplicado a los Respaldos de DataFiles. Por
lo tanto, si la Base de Datos es alguna vez dañada, puede ser restaurada desde
un Backup y todo el trabajo hecho desde el Backup puede ser recuperado.
Segundo, cuando el Log Buffer esta a una
tercera parte de lleno, LGWR vaciará a disco. Se trata de rendimiento. Si el
Log Buffer es pequeño (usualmente debería ser) esta tercera parte de lleno
(trigger) forzara a LGWR a escribir el Buffer a disco en casi tiempo real,
incluso si no hay transacciones para confirmar. El Log Buffer para muchas
aplicaciones será de tamaño óptimo de solo unos pocos megabytes. Las
aplicaciones generaran suficiente Redo para llenar una tercera parte es una
fracción de segundo, así LGWR será forzado a fluir los Change Vectors a disco
continuamente, en casi tiempo real. Entonces, cuando una sesión hace COMMIT,
probablemente no haya nada que escribir, así el COMMIT completará casi
instantáneamente.
Tercero, cuando DBWn necesita escribir
Buffers Sucios del Database buffer Cache a los DataFiles, antes de hacerlo, así
señalara a LGWR para vaciar el Log Buffer a los Online Redo Log Files. Esto es
para asegurar que siempre será posible revertir una transacción sin confirmar.
El mecanismo de Transaction Rollback se explica completamente en el Capitulo
11. Por ahora, es necesario saber que es perfectamente posible que DBWn
escribir una transacción sin confirmar a los DataFiles. Esto está muy bien.
Siempre y cuando el Undo Data necesario para reversar la transacción se garantizar
estar disponible. La generación de Undo Data también genera Change Vectors:
pues estos estarán en los Redo Log Files antes que de los DataFiles sean
actualizados, entonces el Undo Data necesario para regresar la transacción (si
esto es necesario) puede ser reconstruido si es necesario.
Tenga en cuenta que se puede decir que hay
un tiempo de Tres Segundos de espera que causa a LGWR escribir. De hecho, el
tiempo de espera esta en DBWR-pero porque LGWR siempre escribirá justo antes de
DBWn. En efecto, hay tres segundos de tiempo de espera sobre LGWR también.
EXAMEN
Cuando el LGWR vaciará el Log Buffer a
disco? En un COMMIT, cuando el Log Buffer esta a una tercera parte de lleno,
justo antes de que DBWn escriba.
EN EL TRABAJO.
De hecho, es posible prevenir el LGWR
escribir-on-commit. Si se hace esto, las sesiones no tendrán que esperar a que
LGWR cuando hay COMMIT: ellos emiten el comando y luego seguir trabajando. Esto
mejorará el rendimiento pero también puede significar que el trabajo puede
perderse. Llega a ser posible para una sesión a COMMIT, entonces, para la
instancia halla un fallo antes de que LGWR guarde los Change Vectors. Habilite
esto con cuidado! Es peligroso, y casi nunca es necesario. Hay solo unas pocas
aplicaciones donde el rendimiento es más importante que la perdida de datos.
CKPT, EL PROCESO CHECKPOINT.
El propósito de CKPT cambio dramáticamente
entre la versión 8 y la versión 8i de la Base de Datos Oracle. En la versión 8
y anteriores, CheckPoints fueron necesarios en intervalos regulares para
asegurarse que en caso de un fallo (Por ejemplo, si el equipo servidor debe ser
reiniciado) en la instancia de la Base de Datos podría ser recuperada
rápidamente. Estos CheckPoints fueron iniciados por CKPT. El proceso de
recuperación está reparando el daño hecho por el fallo en la Instancia. Esto es
completamente descrito en el Capitulo 15.
En resumen, después de un accidente, todos
los Change Vectors de referencia a los Buffers sucios (Buffers que no había
sido escrito a disco por DBWn en el momento del fallo) deben ser extraídos del
Redo Log, y aplicado a los Data Block. Este es el proceso de recuperación.
CheckPoints Frecuentes se aseguraría que los Buffers Sucios fueran escritos a
discos rápidamente, por lo tanto, reduciendo la cantidad de Redo que tendría
que aplicarse después de un accidente y por lo tanto reducir el tiempo tomado
para recuperar la Base de Datos. CKPT fue responsable de señalizar los
CheckPoints regulares.
Desde la versión 8i en adelante, el
mecanismo de CheckPoints a cambiado. En lugar de dejar que DBWN obtener un
trayecto por detrás y luego un CheckPoint de señalización desde 8i en adelante
el DBWn hace CheckPoint Incrementales (que forzara a DBWn a ponerse al día y
hacerlo bien hasta la fecha, con una caída en el rendimiento mientras esto
sucede) en lugar de CheckPoint completos. El mecanismo de CheckPoints
incrementales instruye a DBWn a escribir Buffers sucios en un ritmo constante,
de modo que siempre hay una brecha predecible entre DBWn (que escribe Blocks
con un Algoritmo perezoso) y LGWR (que escribe Change Vectors en tiempo casi
real). CheckPoints incrementales resulta en un rendimiento mucho más suave y
tiempos de recuperación más fiables que el viejo mecanismo de CheckPoint
completo.
El CKPT ya no tiene para señalar los
CheckPoint Completos, pero tiene que hacer un seguimiento de donde en el Flujo
del Redo esta la posición del CheckPoint Incremental (pero tiene que hacer un
seguimiento del lugar de la corriente de hacer de nuevo la posición de punto de
control incremental), y si es necesario dar instrucciones al DBWn para escribir
algunos Buffers Sucios con el fin de impulsar la posición del CheckPoint hacia
adelante. La posición actual del CheckPoint también conocida como el RBA (El
Redo Byte Address), es el punto en el Flujo del Redo en la cual la recuperación
debe iniciar en caso de un accidente en la instancia. CKPT continuamente
actualiza el ControlFile con la posición actual del CheckPoint.
EXAMEN
¿Cuando ocurre un CheckPoint Completo?
Solo a petición, o como parte de una parada de la Base de Datos ordenadamente.
EN EL TRABAJO.
Cuanto más rápido los avances del
CheckPoint Incremental, la recuperación será más rápida después de un fallo.
Pero el rendimiento se deteriorará debido a la carga extra en disco de Entrada/Salida,
como DBWn a escribir Buffer Sucios más rápidamente. Este es un conflicto entre
el tiempo de inactividad mínimo y maximizar el rendimiento.
MMON, EL MANAGEABILITY MONITOR.
MMON es un proceso que se introdujo con la
Base de Datos Versión 10g y es el proceso que permite el auto-monitoreo y
capacidades de auto-tuning de la Base de Datos. La instancia de la Base de
Datos recopila una vasta cantidad de estadísticas sobre la actividad y
rendimiento. Estas estadísticas son acumuladas en la SGA, y sus valores
actuales pueden ser interrogados mediante la emisión de consultas. Para el
ajuste de rendimiento y también para el análisis de tendencias e informes
históricos, es necesario guardar estas estadísticas en almacenamiento a largo
plazo. MMON regularmente (por defecto, cada hora) captura estadísticas de la
SGA y escribe luego al Diccionario de Datos, donde se pueden almacenar por
tiempo indefinido (aunque por defecto, se mantiene por solo ocho días).
Cada momento que MMON recopila un conjunto
de estadísticas (conocido como snapshot-instantaneas), también lanza el
Automatic Database Diagnostic Monitor, el ADDM. El ADDM es una herramienta que
analiza la actividad de la Base de Datos mediante un sistema experto
desarrollado durante muchos años por muchos DBAs. Se observa dos snapshots (por
default, el actual y previo snapshot) y se hacen observaciones y
recomendaciones con respecto al rendimiento. En el Capitulo 13 se describe el
uso del ADDM (y otras herramientas) para desarrollar ajustes.
Así como la recopilación de snapshots,
MMON continuamente monitorea la Base de Datos y la instancia para comprobar si
alguna alerta debería elevarse. El uso de Alert System está cubierto para el
segundo examen OCP. Algunas condiciones de alerta (tales como advertencias
cuando los limites en almacenamiento son alcanzados) están habilitados por
default; otros pueden ser configurados por el DBA.
EXAMEN.
Por defecto, MMON recopila un snapshot y
la lanza el ADDM cada hora.
MMNL, EL MANAGEABILITY MONITOR LIGTH
El MMNL es un proceso que apoya al MMON.
Hay momentos en que la actividad programada MMON no es suficiente. Por ejemplo,
MMON vuelva la información estadística acumulada en la SGA a la base de datos de
acuerdo a una programación: por default cada hora. Si los buffers de memoria
utilizados para acumular esta información antes de llenar MMON se debe encarga
de descargar, MMNL se encargará de volcar los datos.
MMAN, EL MEMORY MANAGER.
MMAN es un proceso que fue introducido con
la Base de Datos versión 10g. Este permite la gestión automática de las
asignaciones de memoria.
Antes de la versión 9i de la base de
datos, la gestión de memoria en el entorno Oracle estaba lejos de ser
satisfactoria. La memoria PGA asociada con procesos de servidor de sesión era
intransferible: un proceso servidor tomaría la memoria del Pool de memoria
libre del sistema operativo y nunca regresarla. A pesar de que solo podría
haber sido necesaria por un corto tiempo. Las estructuras de memoria SGA eran
estáticas: definidas en el momento de inicio de la instancia, e incambiable a
menos que la instancia fuera reiniciada.
La versión 9i cambio eso: la PGA puede
crecer y disminuir, con el servidor pasando memoria a las sesiones bajo demanda
mientras asegura que la memoria total de PGA asignada se mantiene dentro de
ciertos límites. La SGA y los componentes dentro de ella (con la notable
excepción del Log Buffer) pueden ser cambiados de tamaño dentro de ciertos
límites. La versión 10g automatiza el cambio de tamaño de la SGA: MMAN
monitorea la demanda de Estructuras de memoria SGA y puede cambiar el tamaño
según sea necesario.
La versión 11g lleva la administración de
memoria un paso más allá: toda la necesidad del DBA es fijar un total para el
uso de memoria, y MMAN observara la demanda de memoria PGA y memoria SGA, y
asignara memoria a las sesiones y estructuras SGA como sea necesario, mientras
se mantiene la memoria total asignada dentro de ciertos límites establecido por
el DBA.
EN EL TRABAJO
La automatización de la gestión de memoria
es uno de los mayores avances técnicos de los últimas versiones, la
automatización de una gran parte del trabajo del DBA y dando enormes beneficios
en el rendimiento y utilización de recursos. MMAN lo hace mejor que tú.
ARCn, EL ARCHIVER.
Este es un proceso opcional en cuanto a la
Base de Datos se refiere, pero generalmente un proceso requerido para el
negocio. Sin uno o más procesos ARCn (puede haber desde uno a treinta, llamados
ARC0, ARC1, y así sucesivamente) es posible perder datos. El proceso y
propósito de iniciar ARCn para crear Archive Log Files es descrito a detalle en
el capítulo 15. Por ahora, solo un resumen que se necesita.
Todos los Change Vectors aplicados a los
Data Blocks se ponen en escrito al Log Buffer (por las sesiones que realizan
los cambios) y luego al Online Redo Log Files (por el LGWR). Los Online Redo
Log Files son de tamaño fijo y número: una vez que se han llenado, LGWR los
sobrescribirá con más datos Redo. El tiempo que debe transcurrir antes que
estos suceda depende del tamaño y número de Online Log Files, y la cantidad de
Actividad DML (y por lo tanto la cantidad de Redo Generado) contra la Base de
Datos. Esto significa que el Online Redo Log solo almacena Chance Vectors de reciente
actividad. Con el fin de preservar la historia completa de todos los cambios
aplicados a los datos, los Online Log Files debe ser copiado, ya que se llena y
antes de que sean reutilizados. El ARCn es responsable de hacer esto. A
condición de que estas copias, conocidos como Archive Redo Log Files, están
disponibles, siempre será posible recuperarse de cualquier daño a la Base de
Datos mediante la restauración de copias de seguridad de los DataFiles y la
aplicación de Change Vectors a los extraídos desde todos los Archive Log Files
generados desde los Backups que fueron hechos. A continuación la recuperación
final, para traer hasta la fecha vendrá de los Online Redo Log Files. La
mayoría de las Bases de Datos Transaccionales en producción se ejecutaran en
Modo Archive Log, lo que significa que ARCn se inicia automáticamente y que
LGWR no se le permite sobrescribir un Online Log File hasta que ARCn ha
archivado con éxito a un Archive Log File.
EXAMEN.
LGWR escribe los Online Log Files, ARCn
los lee. En funcionamiento normal, ningún otro proceso los toca en absoluto.
EN EL TRABAJO.
El progreso de los Procesos ARCn y el
estado de las destinaciones a las cuales son escritas deben ser monitoreados.
Si archivado falla, la Base de Datos finalmente se colgara. Este monitoreo se
puede hacer a través del sistema de alerta.
RECO, EL PROCESO RECOVERER.
Una transacción distribuida es una
transacción que implica cambios a dos o más Bases de Datos. Las transacciones
distribuidas son diseñadas por los programadores y operan atraves de database
Links. Considere este ejemplo:
update employees set salary=salary * 1.1
where employee_id=1000;
update employees@dev set salary=salary *
1.1 where employee_id=1000;
commit;
La primera actualización se aplica a una
fila en la Base de Datos Local; la segunda se aplica a una fila en una Base de
Datos remota identificada por el Database Link DEV.
El comando COMMIT instruye a ambas Bases
de Datos para confirmar la transacción, cual consiste en ambas declaraciones.
Una descripción completa de Procesamiento de COMMIT aparece en el capítulo 10.
Las transacciones distribuidas requieren de un COMMIT de Dos-Fases
(Confirmación de dos fases). El COMMIT en cada Base de Datos debe ser
coordinado: si uno fuera a falle y los otros fueran a tener éxito: Todos los
datos estarían en un estado incoherente. El COMMIT de Dos-Fases prepara cada
Base de Datos para instruir a sus LGWR para vaciar el Log Buffer a Disco
(Primera Fase), y una vez esto confirmado, la transacción es marcada como
confirmada en todas partes (Segunda Fase). Si algo va mal en cualquier lugar de
las dos fases. RECO tomara medidas para cancelar el COMMIT y hará un RollBack
al trabajo en todas las Bases de Datos.
ALGUNOS OTROS PROCESOS BACKGROUND.
- CJQ0, J000. Estos gestionan los trabajos
programados para ejecutarse periódicamente. El Job Queue Coordinator, CJQn,
monitorea la cola de trabajos y envía trabajos a uno de varios procesos de la
cola de trabajo, Jnnn, para su ejecución. Tema del segundo Examen OCP.
- D000. Este es un proceso despachador que
envía llamadas SQL a los procesos de Servidor compartido, Snnn, si el mecanismo
de servidor compartido ha sido habilitado. Este es descrito en el capítulo 6.
- DBRM. El Database Resource Manager es
responsable de establecer los planes de recursos y otras tareas relacionadas
con gestión de recursos. Tema del Segundo examen OCP.
- DIA0. El proceso Diagnosability Cero
(solo uno se utiliza en la versión actual) es responsable de la detección de
bloqueos y resolución de DeadLock. DeadLocks y su resolución son descritos en
el capítulo 10.
- DIAG. El Proceso Diagnosability (no
numero cero) realiza volcados de diagnostico y ejecuta comandos oradebug
(oradebug es una herramienta para investigar problemas dentro de la instancia).
- FBAR. El proceso FlashBack Data Archiver
archiva as filas históricas de las tablas de seguimiento en los Datos de
Archivos FlashBack. Esta es una instalación para asegurarse de que siempre es
posible consultar datos como lo fue en un momento en el pasado.
- PSP0. El proceso spawner tiene la tarea
de crear y gestionar de otros procesos de Oracle y no está documentado.
- QMNC, Q000. El Queue Manager Coordinator
supervisa colas en la Base de Datos y asigna procesos Qnnn para encolar y
quitar mensajes hacia y desde estas colas .Las colas puede ser creadas por
programadores y también se utilizas Streams .Por ejemplo utilice las colas para
almacenas las transacciones que necesitan ser propagadas a las Bases de Datos
Remotas.
- SHAD. Estos se llamaran TNS V1-V3 en
sistemas Linux. Estos procesos son procesos servidor que apoyan a sesiones de
usuarios. En la figura hay solo una, ya que solo un usuario está conectado
actualmente. El usuario que ha emitido la consulta.
- SMCO, W000. El Proceso Space Management
Coordinator, coordina la ejecución de tareas diversas relacionadas con la
gestión del espacio, tales como la asignación de espacio dinámico y
recuperación del espacio. Se genera de forma dinámica los procesos de esclavo
(Wnnn) para implementar la tarea.
- VKTM. El Virtual Keeper of Time es
responsable de mantener el seguimiento del tiempo. Más complicado de lo que uno
podría pensar. Particularmente en un entorno de Clustered.
EJERCICIO 2-3.
INVESTIGAR LOS
PROCESOS EJECUTANDOSE EN SU INSTACIA.
En este ejercicio ejecutara consulta para
ver que procesos Background están ejecutándose en su Instancia.
1.Conéctese a la Base de Datos con el
usuario SYSTEM.
2.Determine que procesos están
ejecutándose, y cuantos de cada uno:
select program from v$session order by
program;.
select program from v$process order by
program;.
3.Estas consultas darán resultados similares:
cada proceso debe tener una sesión (incluso los procesos Background), y cada
sesión debe tener un proceso. Los procesos que pueden ocurrir varias veces,
tendrán un sufijo numérico, a excepto de los procesos que apoyan a las sesiones
de usuario: todos estos tendrán el mismo nombre.
4.Demostrar la puesta en marcha de los
procesos servidor cuando la sesiones se realizan, contando el número de
procesos de servidor (en Linux o cualquier plataforma Unix) o el número de
Oracle Threads (en Windows). La técnica es diferente en las dos plataformas,
porque en Linux/Unix, los procesos de Oracle son procesos separados del sistema
operativo, pero en Windows son hilos dentro de un proceso de sistema operativo.
A.En Linux, ejecute este comando desde el
prompt del Sistema Operativo:
ps –ef | grep oracle | wc -1
Este contará el numero de procesos
ejecutándose que tienen la cadena oracle en su nombre; este incluye todos los
procesos de servidor de sesiones (y posiblemente algunos otros).
Lance una sesión SQL/PLUS, y vuelva a
ejecutar el comando anterior: utilice el comando host para lanzar un Shell del
sistema operativo desde dentro la sesión de SQL/PLUS. Usted verá el numero de
procesos incrementará. Salir de la sesión, y usted verá que el número ha
disminuidos de nuevo.
Observe en la ilustración como el número
de procesos cambia de 4 a 5 y viceversa: la diferencia es la puesta en marcha y
terminación de los procesos servidor de apoyo a la sesión de SQL/PLUS.
B.En Windows, lance el Task Manager.
Configurar para mostrar el numero de hilos dentro de cada proceso: en la
pestaña Ver, tome “Seleccionar columnas y marque la casilla de verificación
hilos. Busque el proceso de ORACLE.EXE y tenga en cuenta el número de subprocesos.
En la ilustración siguiente, esto es en la actualidad a los 33.”.
Lance una nueva sesión contra la
instancia, y usted verá como incrementan los hilos. Salir de la sesión, y este
decrementará.
DENTRO DEL EXAMEN.
LA RELACIÓN
ENTRE PROCESOS, ESTRUCTURAS DE MEMORIA Y ARCHIVOS.
Es vital tener una comprensión de la Relación
entre la Instancia y la Base de Datos. Este enlace es hecho por los procesos
Background. Cuando una instancia inicia, la SGA es construida en memoria.
Entonces los procesos Background se conectan con los archivos de Base de Datos
en disco. Los procesos son el enlace entre las estructuras de memoria y las
estructuras de disco.
Los DataFiles usualmente serán fuera de
fecha: que no podrán contar con el trabajo que se ha hecho en memoria, porque
el DBWn no ha encontrado el momento de escribir el trabajo a los archivos. No
hay problema-en memoria, la información es en tiempo real, y eso es lo que las
sesiones de usuario verán. En contraste, el Online Redo Log File son hasta la
fecha, porque el LGWR escribe en casi tiempo real y cuando un usuario dice COMMIT,
este hace la escritura en tiempo real.
Always be absolutely clear on which
processes are reading and writing memory structures, and which are reading and
writing disk structures.
No hay comentarios:
Publicar un comentario