10g para administradores
Consejeros:
Los "Consejeros" son componentes del nuevo servidor Oracle 10g que tratan de automatizar tareas que en versiones anteriores el DBA tenía que realizar manualmente. Esto no significa que la figura del DBA pierda peso, sino que le libera de ciertas tareas más repetitivas y monótonas y le permiten dedicarse a otras más complejas y generales, como por ejemplo, diseñar una política de copia de seguridad y restauración coherente. Estos Consejeros también nos aportan información sobre la utilización del espacio y el rendimiento de la Base de Datos.
El más importante de todos los Consejeros es el ADDM (Automatic Database Diagnostics Monitor). El ADDM realiza análisis del sistema, identifica los posibles problemas y sus causas potenciales, y por último plantea recomendaciones para solucionarlos. También puede llamar a su vez a otros Consejeros para realizar tareas más específicas.
Las principales características del ADDM son:
- El ADDM se ejecuta automáticamente en forma de proceso en segundo plano de la instancia Oracle cuando se recogen instantáneas (snapshots) con estadísticas de memoria. El proceso se denomina MMON . El ADDM realiza el análisis de las estadísticas recogidas entre dos instantáneas.
- Los resultados del análisis se almacenan en el Workload Repository (Repositorio de Carga de Trabajo) para su uso posterior.
- El ADDM utiliza un nuevo modelo de estadísticas, en el que las actividades con un gran consumo de tiempo se analizan en base a la prioridad de cada una.
- El ADDM también puede ejecutarse manualmente.
Los resultados del análisis proactivo realizado por el ADDM se almacenan en el Repositorio de Carga de Trabajo y están disponibles para los usuarios a traves del Enterprise Manager o mediante consultas al Diccionario de Datos. El análisis del ADDM es también la guía fundamental para definir las Alertas del Servidor, donde se definen métricas y valores de alerta para conocer el funcionamiento del Servidor. La consola OEM tiene numerosas páginas dedicadas a mostrar la información del ADDM.
Otros nuevos Consejeros son:
- SQL Tuning Advisor (Consejero de Optimización de Consultas): Es el encargado de plantear posibles mejoras de cara al rendimiento en una consulta SQL.
- SQL Access Advisor : Propone consejos y provee de información acerca de índices, vistas materializadas y logs de vistas materializadas. Es un Consejero dedicado especialmente a temas de DataWarehouse.
- Segment Advisor (Consejero de segmentos): Este consejero analiza el uso que hacen del espacio los objetos de la Base de Datos, y plantea posibilidades de compresión de segmentos.
- Undo Advisor : Este consejero sugiere valores para los parámetros relacionados a temas de undo, y cuanto espacio adicional se necesita para soportar la opción Flashback para un tiempo determinado. Sin embargo, la mayor parte de la optimización del espacio de undo es automática en Oracle 10g.
- Redo Logfile Size Advisor (Consejero para el tamaño de los Ficheros de Redo): Determina el tamaño óptimo más pequeño para los ficheros de redo, basándose en el velor del parámetro fast_start_mttr_target y en estadísticas.
Mecanismo de Alertas del Servidor:
Tal y como hemos comentado, el servidor Oracle 10g recolecta y almacena estadísticas en el Repositorio de Carga de Trabajo. Estas estadísticas son analizadas para producir diferentes métricas.
Las alertas generadas por el servidor dependen en gran medida de las métricas disponibles en el Workload Repository. El proceso MMON se levanta cada minuto para computar los valores actuales de cada métrica. Si hemos definido "umbrales" para las métricas, MMON también los comprueba y genera las alertas si es necesario. Entonces la alerta queda almacenada en una cola persistente alert_que propiedad de SYS.
Basandose en los valores obtenidos en la alert_que, la consola OEM se encarga de generar las notificaciones. Los DBAs las pueden recibir via e-mail, o bien chequeando la OEM.
La diferencia entre este nuevo sistema de alertas y las antiguas alertas del Enterprise Manager radica en el modo en que son generadas. Las nuevas Alertas del Servidor dependen de las métricas definidas y de sus correspondientes umbrales, que son gestionados por el servidor y acceden a la SGA directamente, mientras que las alertas de OEM eran recogidas por el Agente (Intelligent Agent).
Administración Proactiva del Espacio:
En Oracle 10g, la utilización del disco por parte de los tablespaces es administrada por la Base de Datos. El Mecanismo de Alertas de Servidor monitoriza el uso del disco por los tablespaces.
La información recogida en el AWR (Automatic Workload Repository) se usa también para realizar un análisis de crecimiento de la Base de Datos. El proceso MMON verifica los umbrales de cada tablespace, para ver si en algún caso está siendo superado (los umbrales se especifican en este caso en porcentajes) y en caso afirmativo genera una alerta.
Otra importante y útil característica nueva en Oracle 10g es la facilidad para comprimir los segmentos. En versiones anteriores, mover o redefinir el segmento era la única manera de liberar espacio una vez asignado por debajo de la HWM (High Water Mark) del segmento.
En Oracle 10g se pueden comprimir los segmentos. Cuando un segmento es comprimido, sus datos son compactados y la HWM desciende, y el espacio no usado se vuelve a asignar al tablespace que contiene ese segmento. Esto sólo es posible en tablespaces con ASSM (Automatic Segment Space Managed). Por ejemplo, si quisiéramos reducir el segmento asignado a la tabla art_ventas utilizaríamos la sentencia:
ALTER TABLE art_ventas SHRINK SPACE CASCADE;
Configuración de Servidor Compartido:
En la arquitectura de Servidor Compartido, el listener asigna a cada nueva sesión uno de los dispatchers disponibles. Cuando el usuario realiza peticiones, el dispatcher las envía al servidor compartido. El dispatcher actúa como coordinador entre la sesión de usuario y el servidor compartido.
Un dispatcher es capaz de soportar muchas conexiones de clientes concurrentes. Cada conexión de cliente utiliza un circuito virtual . Un circuito virtual es una porción de memoria compartida usada por el dispatcher para gestionar las peticiones del cliente y las respuestas del servidor.
Un proceso inactivo de servidor compartido recoge un circuito virtual de la cola común, procesa la petición y abandona el circuito virtual antes de intentar recoger otro de la cola común. De esta manera, un pequeño número de procesos de servidor son capaces de atender un número muy grande de usuarios, a la vez que reduce los requerimientos hardware del sistema.
Hay que señalar que no todas las aplicaciones están capacitadas para usar el servidor compartido, pero el balanceo de carga en un entorno RAC puede beneficiarse del uso del servidor compartido. La siguiente imagen muestra de forma gráfica todo lo explicado anteriormente.
En versiones anteriores a Oracle 10g, se necesitaba especificar al menos un dispatcher para habilitar la configuración de servidor compartido. Esto, como ya sabemos, se hace en el parámetro de inicialización (dispatchers) del fichero de parámetros que estemos utilizando.
Con Oracle 10g, incluso sin especificar un dispatcher en el parámetro de inicio, se puede habilitar la configuración Shared Server especificando un valor distinto de 0 para el parámetro shared_servers. El comportamiento predeterminado es que Oracle creará un dispatcher para protocolo TCP/IP automáticamente. De esta forma resulta más sencillo configurar el entorno del servidor compartido de Oracle. El parámetro quedaría de la siguiente manera:
DISPATCHERS="(PROTOCOL=tcp)"
Cuando, mientras está corriendo el servidor, necesitamos usar shared servers, simplemente cambiamos el parámetro dinámico shared_server a un valor mayor que 0 con la opción ALTER SYSTEM. Como ocurre con otros parámetros, podemos elegir el ámbito (Scope) del cambio en el parámetro, para esta ejecución o para futuros arranque de instancia. Por ejemplo:
Hay otros parámetros relacionados con el entorno de servidor compartido, pero no son obligatorios en esta nueva versión. De hecho, cuando especifiquemos valor para shared_servers, nuestro sistema estará funcionando en modo servidor compartido.
Los parámetros que en versiones anteriores tenían el prefijo MTS están descatalogados. Esto significa que si intentamos arrancar una instancia usando estos parámetros recibiremos el siguiente error:
'ORA-25138: [parameter] initialization parameter has been made obsolete'
La siguiente tabla muestra el listado de parámetros absoletos y los nuevos parámetros que los sustituyen:
PARÁMETROS OBSOLETOS | NUEVOS PARÁMETROS |
mts_servers | shared_servers |
mts_max_servers | max_shared_servers |
mts_dispatchers | dispatchers |
mts_max-dispatchers | max_dispatchers |
mts_circuits | circuits |
mts_sessions | shared_server_sessions |
mts_listener_address | local_listener |
NOTA : Todos los nuevos parámetros listados en esta tabla son dinámicos, con lo que se puede cambiar su valor sin detener la instancia.
También se han añadido nuevas vistas informativas sobre el estado de los dispatchers, por ejemplo v$dispatcher_config, que se puede consultar uniéndola con la vista v$dispatcher para mostrar toda la información de un determinado dispatcher. Una consulta típica sería:
SQL> SELECT name, dispatchers, substr(service,1,20) service, idle, busy
FROM v$dispatcher,v$dispatcher_config
WHERE v$dispatcher.conf_indx = v$dispatcher_config.conf_indx ;
| NAME | DISPATCHERS | SERVICE | IDLE | BUSY |
| ---- | ----------- | ------------- | ---------- | -------- |
| D000 | 1 | LONDBXDB | 1641097 | 8 |
Gestión de Transacciones:
El usuario puede hacer rollback de transacciones con el comando ROLLBACK y también durante una sesión de recuperación de la Base de Datos. Cuando el sistema falla y empieza la recuperación de la instancia, el proceso SMON examina los segmentos de rollback/undo y recupera las transacciones no completadas. En versiones anteriores de Oracle, podíamos monitorizar la recuperación paralela de transacciones con estas dos vistas: v$fast_start_servers y v$fast_start_transactions . Sin embargo lo que no podíamos monitorizar eran las transacciones normales de las que se había hecho rollback o que habían sido recuperadas por SMON. Todo esto es ahora posible con los nuevos cambios introducidos en Oracle 10g.
Ahora, podemos ver la información histórica sobre la recuperación de la transacción y calcular la duración media de la fase de rollback. Dado un estado de la recuperación, podemos saber cuanto trabajo se ha hecho y cuanto queda. Así, es posible estimar el tiempo de recuperación de transacciones y adaptar el parámetro fast_start_parallel_rollback para optimizar el rendimiento del sistema.
Nuevas columnas:
La vista v$fast_start_transactions almacena información sobre el progreso de las transacciones que Oracle está recuperando y ha recuperado. Hay nuevas columnas que se han añadido a esta vista, que ayudan a comprender la identidad de las transacciones.
NOMBRE | TIPO | DESCRIPCIÓN |
XID | RAW(8) | Transaction ID |
PXID | RAW(8) | Transaction ID de la transacción padre |
RCVSERVERS | NUMBER | Servidores trabajando sobre esta transacción |
La vista v$fast_start_servers nos da información sobre los servidores que están realizando o han realizado recuperación paralela de transacciones. Una nueva columna ha sido añadida: XID, que nos da el identificador de la transacción en la que un servidor está trabajando.
La siguiente sentencia se usa para comprobar el estado de las transacciones recuperadas después de la apertura de la instancia. La primera salida muestra que la transacción está siendo recuperada, mientras que la segunda muestra que la transacción ha sido recuperada. El total de bloques recuperados también se muestra.
SELECT state, undoblocksdone, undoblockstotal, cputime
FROM v$fast_start_transactions;
| STATE | UNDOBLOCKSDONE | UNDOBLOCKSTOTAL | CPUTIME |
| -------- | -------------- | --------------- | ------- |
| RECOVERING | 324 | 1145 | 12? |
SQL> /
| STATE | UNDOBLOCKSDONE | UNDOBLOCKSTOTAL | CPUTIME |
| -------- | -------------- | --------------- | ------- |
| RECOVERED | 1145 | 1145 | 28 |
Cambio en la vista v$session_longops:
Más operaciones han sido añadidas a esta vista, que muestra el estado de varias operaciones que ocupan más de 6 segundos de proceso en el servidor. Normalmente, son operaciones relacionadas con copias de seguridad y recuperación, recolección de estadísticas o ejecución de consultas. En cada versión de Oracle se añaden nuevas operaciones para esta vista, y en Oracle 10g se han añadido las operaciones de ROLLBACK y ROLLBACK TO .
MAXTRANS y Concurrencia:
En releases anteriores del Servidor Oracle, el valor de MAXTRANS se usa para representar un atributo físico para objetos como tablas, índices o cluster. Representa el número máximo de transacciones de modificación concurrentes para cualquier bloque del segmento asignado a ese objeto.
En Oracle 10g, estos objetos están preconfigurados para conseguir la máxima concurrencia. Oracle ahora permite 255 transacciones concurrentes para cada bloque de datos.
Recogida de estadísticas:
Una tarea habitual del DBA el la recogida de estadísticas para las tablas y los índices residentes en los esquemas de usuarios. Con la definitiva desaparición del RBO (Optimizador basado en reglas) y la tendencia de adaptar las nuevas aplicaciones al CBO (Optimizador basado en costes) conviene analizar las nuevas mejoras en temas de estadísticas.
Oracle 10g introduce muchas nuevas características en la recogida de estadísticas, como por ejemplo la capacidad de recoger estadísticas de los objetos del diccionario de datos. También se han añadido mejoras en los paquetes proporcionado por Oracle para temas de estadísticas.
Comentarios