Archivos de Control - Oracle

Un Archivo de Control es un archivo binario pequeño que forma parte de una base de datos oracle. El archivo de control se utiliza para hacer un seguimiento del estado de la abse de datos y la estructura fisica.

Cada Base de datos Oracle debe tener al menos un archivo de control, sin embargo se recomienda crear mas de uno. Cada copia de un archivo de control debe ser almacenado en una unidad de disco diferente multiplexada para pdoer hacer el registro en linea.
Se utilizan apra minimizar el riesgo de que todos los archivos de control sean borrados o estend dañados.

El Archivo de Control contiene informacion como:

• Nombre de la BD
• Marca de la hora de creacion de la BD
• Nombres y ubicaciones de archivos de datos
• Los nombres y ubicaciones de los Redo Log
• El actual numero de secuencia de registro
• Informacion de Checkpoint
• Recientes copias de seguridad RMAN adoptadas

Lista de archivos de control en el uso de

From SQL*Plus (connect SYS AS SYSDBA): De SQL * Plus (conectar SYS AS SYSDBA):

SHOW PARAMETERS control_files; Control_files SHOW parámetros;

En una consulta:

SELECT * FROM v$controlfile; SELECT * FROM v $ CONTROLFILE;

Control de contenidos de los archivos

 SELECT * FROM v$controlfile_record_section; Controlfile_record_section SELECT * FROM v $;

Copia de seguridad

Copia de seguridad del archivo control de udump en formato de texto:

 ALTER DATABASE BACKUP CONTROLFILE TO TRACE; BACKUP DATABASE ALTER CONTROLFILE a Trace;

Haga una copia binaria del archivo de control:

 ALTER DATABASE BACKUP CONTROLFILE TO '/tmp/control.bkp'; BACKUP DATABASE ALTER CONTROLFILE A '/ tmp / control.bkp'; 

Fuente: ORAFAQ

Listener - Oracle

QUE ES EL LISTENER ORACLE?

TNS Listener es un proceso servidor que provee la conectividad de red con la base de datos Oracle. El listener está configurado para escuchar la conexión en un puerto específico en el servidor de base de datos. Cuando una se pide una conexión a la base de datos, el listener devuelve la información relativa a la conexión. La información de una conexión para una instancia de una base de datos provee el nombre de usuario, la contraseña y el SID de la base de datos. Si estos datos no son correctos se devolverá un mensaje de error.

• Por defecto el puerto del listener es el 1521
• El listener no limita el número de conexiones a la base de datos

Toda la información del listener la contiene un archivo denominado listener.ora ( $ORACLE_HOME/network/admin. )

El comando para gestionar el listener es lsnrctl. Mediante este comando podemos:

• Parar el listener.
• Ver el estado del listener.
• Arrancar el listener.
• Rearrancar el listener.

Para que desde fuera del servidor donde está instalada la base de datos se pueda acceder a la misma el servicio denominado listener ha de estar activado, o como se suele decir, ha de estar escuchando.

Puede pasar que la base de datos esté correctamente levantada y no se pueda conectar desde otros servidores, que también están correctamente configurados (TNSNAMES correcto, etc.). En estos casos puede ser que el listener tenga algún problema, o simplemente que no haya sido iniciado. Consultar el estado del mismo, arrancarlo o pararlo es muy sencillo. Sólo hay que abrir una sesión de línea de comandos (consola, terminal, etc. ) con el usuario con el que se ha instalado la base de datos, y ejecutar el comando lsnrctl con los siguientes parámetros para cada caso:

• Comprobar su estado: > lsnrctl status
• Parar el listener: > lsnrctl stop
• Levantar el listener: > lsnrctl start

Hay que tener en cuenta que cuando se para el listener no se cierran las conexiones que ya están dentro de la base de datos, por lo que una parada momentánea no suele ser muy traumática, sólo se rechazarán las conexiones que intenten entrar mientras el listener esté parado, no ha de afectar a nadie que tenga ya una sesión abierta.

Fuente: MiOracle y DataPrix

Roles o Funciones de un Administrador de Base de Datos

ADMINISTRADOR DE BASE DE DATOS

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.

El diseño lógico y físico de las bases de datos a pesar de no ser obligaciones de un administrador de bases de datos, es a veces parte del trabajo. Esas funciones por lo general están asignadas a los analistas de bases de datos ó a los diseñadores de bases de datos.

Área Global del Sistema, SGA

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

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 del fichero init.ora.

Como el tamaño del buffer suele ser pequeño para almacenar todos los bloques de datos leidos, su gestión se hace mediante el algoritmo LRU.

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 registros redo log en los ficheros redo log.

El tamaño del buffer redo log se fija por el parámetro LOG_BUFFER.

Área de SQL Compartido, Shared SQL Pool

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. De esta manera se premia la uniformidad en la programación de las aplicaciones. La igualdad se entiende que es lexicografica, espacios en blanco y variables incluidas. El contenido de la zona de SQL compartido es:

• Plan de ejecución de la sentencia SQL.
• Texto de la sentencia.
• Lista de objetos referenciados.

Los pasos de procesamiento de cada petición de análisis de una sentencia SQL son:

• Comprobar si la sentencia se encuentra en el área compartida.
• Comprobar si los objetos referenciados son los mismos.
• Comprobar si el usuario tiene acceso a los objetos referenciados.

Si no, la sentencia es nueva, se analiza y los datos de análisis se almacenan en la zona de SQL compartida.

También se almacena en la zona de SQL compartido el caché del diccionario. La información sobre los objetos de la BD se encuentra almacenada en las tablas del diccionario. Cuando esta información se necesita, se leen las tablas del diccionario y su información se guarda en el caché del diccionario de la SGA.

Este caché también se administra mediante el algoritmo LRU. El tamaño del caché está gestionado internamente por el servidor, pero es parte del shared pool, cuyo manaño viene determinado por el parámetro SHARED_POOL_SIZE.

PROCESOS BACKGROUND DE UNA BASE DE DATOS

System Monitor, SMON

El SMON 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.

Process Monitor, PMON

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.

Database Writer, DBWR

El proceso DBWR 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.

Log Writer, LGWR

El proceso LGWR 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.

Archiver, ARCH

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.

PGA

Las siglas provienen de Program/Private Global Area, y 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 como por ejemplo sus variables globales, el estado actual de cada cursor (SQL) que se ejecuta... etc.

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: a) area persistente: perdura durante toda la vida del cursor. Guarda las bind variables además de otras cosas; b) area 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) que se explican más adelante. 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.