Parámetros de inicialización de Oracle

Para ejecutar ArcGIS no es necesario cambiar la instancia Oracle de la configuración predeterminada. No obstante, en sistemas más grandes, puede realizar algunos cambios en la configuración de la instancia de Oracle.

Siempre que inicie una instancia de Oracle, Oracle lee sus parámetros de inicialización desde el archivo init.ora o desde el archivo de parámetros del servidor, spfile.ora. Ambos archivos definen las características de la instancia, pero se gestionan de forma diferente.

El archivo init.ora se encuentra en el directorio o carpeta ORACLE_BASE/admin/<ORACLE_SID>/pfile . Habitualmente, init.ora es un nombre que se da al archivo de inicialización de una instancia de la base de datos de Oracle, pero para una instancia determinada, el archivo es en realidad init<oracle SID>.ora. Por ejemplo, si el ID de sistema de Oracle (SID) es GIS, el archivo init.ora de esta instancia sería initGIS.ora.

La modificación de los parámetros con el comando ALTER SYSTEM se reflejará automáticamente en el archivo de parámetros del servidor si la instancia se ha iniciado mediante ese método. Si la instancia se inició con un archivo init.ora, deberá editar manualmente el archivo con un editor de texto si desea que los cambios en los parámetros del sistema afecten más que a la instancia actual de la base de datos.

Parámetros que afectan a la memoria compartida

Esta sección describe algunos de los parámetros que controlan la asignación de la memoria compartida. Para una obtener una descripción detallada de los parámetros de inicialización de Oracle, consulte Oracle Server Tuning de su versión de Oracle.

OPEN_CURSORS

El parámetro de inicialización de Oracle OPEN_CURSORS especifica el número de cursores que una sesión puede tener abiertos a la vez. El valor por defecto es 300. Si la sesión intenta abrir un nuevo cursor pero ya tiene el número máximo abierto de cursores, se devolverá el error -1000 de Oracle. ArcGIS mantiene abiertos los cursores que se ejecutan con más frecuencia para mejorar el rendimiento. Si su parámetro OPEN_CURSORS de Oracle no está establecido lo suficientemente alto, se producirá el error antes mencionado. La documentación de Oracle indica que establecer el parámetro en un valor grande no afecta negativamente. Por lo tanto, puede establecer un valor enormemente grande, por ejemplo, en 2.000; esto elimina de forma eficaz cualquier límite en el número de cursores abiertos desde un punto de vista práctico, a la vez que sigue ofreciendo una medida de protección contra un proceso no autorizado que intente consumir una cantidad exagerada de recursos del cursor. Si, en su lugar, desea calcular el número posible de cursores que ha abierto una sesión, la siguiente fórmula, basada en el modo de datos de su organización, puede utilizarse como orientación:

• Diversos cursores de la administración de datos de ArcGIS (20) +
• Diversos bloques PL/SQL anónimos (20) +
• Consultas espaciales—6 posible por capa +
• Consultas de archivo de registro (11) +
• Consultas varias utilizadas al editar tablas versionadas—12 por capa o tabla versionadas

Por lo tanto, una aplicación de ArcMap con 10 capas que se editan en el documento puede tener, posiblemente, 231 cursores abiertos (20 + 20 + 60 + 11 + 120 = 231). Si detecta que con frecuencia se le acaban los cursores, puede aumentar el valor del parámetro OPEN_CURSORS en incrementos de 50 ó 100.

Nota:

Oracle 10g está preconfigurado para generar una alerta de servidor cuando el número de cursores abiertos para la instancia supera los 1.200. Puesto que 1.200 cursores no es una situación anormal para la geodatabase, es posible que desee aumentar el umbral de esta alerta para eliminar avisos innecesarios en la cola de alertas.

Una circunstancia en la que posiblemente tenga que reducir el valor del parámetro es cuando los recursos de la memoria del servidor que ejecutan la instancia de Oracle no tengan suficiente memoria disponible para cada proceso dedicado de Oracle. Lograr el tamaño de requisitos de memoria para el proceso dedicado requiere hacer un prototipo de la aplicación. Varios parámetros de Oracle y el comportamiento de la aplicación, tales como una declaración SQL, pueden afectar a los requisitos de memoria del proceso.

SESSION_CACHED_CURSORS

Oracle controla las declaraciones SQL que se envían para cada sesión. Si detecta que la misma declaración se ha enviado varias veces, traslada la declaración a la memoria caché del cursor y mantiene el cursor abierto para volver a utilizarlo posteriormente. El parámetro SESSION_CACHED_CURSORS controla el número de cursores que se permiten en la memoria caché del cursor. El valor por defecto para SESSION_CACHED_CURSORS varía en función de la versión de Oracle. Si su instancia no está configurada para almacenar un mínimo de 50 cursores en memoria caché, aumente el valor de este parámetro a 50.

UNDO_MANAGEMENT y UNDO_TABLESPACE

Oracle almacena múltiples copias de datos que el usuario está modificando en ese momento. Cuando la transacción que modifica los datos está en curso, una copia de los datos originales se utiliza para proporcionar una vista de lectura de la base de datos para las demás sesiones. Además, los usuarios que realizan las modificaciones pueden elegir deshacer el trabajo emitiendo una declaración ROLLBACK, o sus procesos podrían fallar en medio de la transacción, precisando que Oracle deshaga su trabajo en curso para restaurar la base de datos en un estado consecuente.

Para admitir cada uno de estos escenarios, Oracle almacena los datos editados previamente en una estructura de datos espacial, un segmento de deshacer o retroceso. Puede establecer los parámetros UNDO_MANAGEMENT y UNDO_TABLESPACE para que Oracle cree y gestione automáticamente los segmentos de deshacer. Para habilitar la gestión automática de deshacer, establezca en primer lugar UNDO_MANAGEMENT en auto. Seguidamente, establezca UNDO_TABLESPACE en el nombre del espacio de tabla que almacenará los segmentos de deshacer gestionados por el sistema.

Tenga en cuenta que no puede utilizar un espacio de tabla arbitrario para almacenar los segmentos de deshacer gestionados por el sistema. Debe designar el espacio de tabla como un espacio de tabla de deshacer en el momento de la creación. Para más información acerca de controlar y gestionar el comportamiento automático de deshacer, lea la Guía de Oracle Database Administrator.

SESSIONS

La geodatabase está configurada para permitir 48 ó 64 conexiones simultáneas por defecto, en función del sistema operativo. Si configura la tabla del diccionario de datos SDE.SERVER_CONFIG para permitir un número mayor de conexiones, es posible que necesite modificar el parámetro SESSIONS de Oracle para dar cabida al nuevo ajuste.

El parámetro SESSIONS limita directamente el número total de sesiones simultáneas que permitirá Oracle. Si el valor predeterminado es insuficiente para admitir el número de conexiones de geodatabase que usted espera, aumente este parámetro al número de conexiones actuales anticipadas y un mínimo de un 10 por ciento más para admitir las funciones internas de Oracle.

Nota:

Si utiliza la configuración del servidor compartido de Oracle, el parámetro SHARED_SERVER_SESSIONS se comporta como el parámetro SESSIONS descrito anteriormente, con la excepción de que sólo se aplica a las conexiones del servidor compartido. Todas las sesiones—el servidor compartido y el servidor dedicado—están limitadas por el parámetro más general SESSIONS.

PROCESSES

Puede limitar el número máximo de procesos que Oracle puede crear con el parámetro PROCESSES. Al utilizar la configuración del servidor dedicado, este proceso corresponde aproximadamente al número de sesiones simultáneas que admitirá la base de datos. Si aumenta el número de conexiones que están permitidas, asegúrese de que el parámetro PROCESSES sea como mínimo tan grande como el número de conexiones de geodatabase más 25 para un conjunto habitual de procesos de fondo de Oracle.

Parámetro que afecta a las estadísticas de Oracle

OPTIMIZER_MODE

Mantenga el valor por defecto del parámetro OPTIMIZER_MODE de Oracle. Para Oracle 10g y 11g, el valor por defecto es all_rows. Este ajuste funciona mejor para la mayoría de bases de datos y mejora la escalabilidad general de su geodatabase.

Parámetros que afectan a la memoria

Debe tenerse mucho cuidado al establecer los parámetros de inicialización que afectan a la memoria. Establecer estos parámetros más allá de los límites impuestos por el recurso de memoria física de la máquina host degrada enormemente el rendimiento.

LOG_BUFFER

El búfer de registro es un componente del Área Global del Sistema de Oracle (SGA) que mantiene en memoria cambios no confirmados en la base de datos hasta que los procesos de fondo de Oracle tengan la oportunidad de grabar esos cambios en un almacenamiento permanente en disco. Como estas grabaciones ocurren con tanta frecuencia—como mínimo cada tres segundos—el búfer de registro no requiere mucho espacio y puede configurarse a un tamaño inferior a 1 megabyte. El tamaño del búfer de registro de rehacer es controlado por el parámetro LOG_BUFFER. El tamaño del búfer del registro por defecto es apropiado para la mayoría de geodatabases. No obstante, para aquellas bases de datos con un nivel elevado de actividad de grabación, es posible que el rendimiento se vea afectado por múltiples usuarios que intenten acceder a la vez al búfer de registro. Diagnosticar y mitigar esta condición requiere unas habilidades avanzadas, tales como controlar retenciones y eventos de espera. Para información más detallada, consulte Oracle Database Performance Tuning Guide y la MetaLink Knowledge Base.

Nota:

De hecho, establecer el LOG_BUFFER en un valor grande para procesar enormes transacciones de carga puede originar una reducción del rendimiento. Puede tener lugar la contención de retenciones entre las transacciones si el búfer del registro está establecido en un valor demasiado grande.

SHARED_POOL_SIZE

El grupo compartido es otro componente de Oracle SGA que mantiene tanto la memoria caché del diccionario de datos como la memoria caché de la biblioteca. La memoria caché del diccionario de datos mantiene información acerca de los objetos de datos, espacio libre y privilegios. La memoria caché de la biblioteca mantiene las declaraciones SQL que se han analizado más recientemente. En general, si el grupo compartido es lo suficientemente grande como para satisfacer los requisitos de recursos de la memoria caché de la biblioteca, será lo suficientemente grande como para mantener la memoria caché del diccionario de datos. Las geodatabases pueden aprovecharse de un grupo compartido mayor que algunas otras aplicaciones de Oracle. ArcGIS mantiene una memoria caché de las declaraciones SQL enviadas por las aplicaciones cliente. Un grupo compartido grande permite que más cursores permanezcan abiertos, con lo cual se reducen las operaciones de gestión del cursor y se mejora el rendimiento. El tamaño del grupo compartido es controlado por el parámetro SHARED_POOL_SIZE. Esri recomienda que establezca el parámetro SHARED_POOL_SIZE en un múltiple de 16 MB para dar cabida a cualquier sistema que Esri admite y que establezca este parámetro en un mínimo de 128 MB:

shared_pool_size = 128,000,000

Las geodatabases muy activas que admiten una utilidad volátil y sistemas de edición por parcelas pueden requerir que el parámetro SHARED_POOL_SIZE se establezca en un número tan alto como 250 MB.

De los tres búfers SGA, el más importante es el grupo compartido. Si el SGA es tan grande como es posible teniendo en cuenta el tamaño de su memoria física, reduzca el tamaño de la memoria caché del búfer para dar cabida a un grupo compartido mayor.

DB_CACHE_SIZE

La memoria caché del búfer es otro componente del Oracle SGA que almacena los bloques de datos más utilizados recientemente. Los bloques de datos son la unidad atómica de Oracle de la transferencia de datos. Oracle lee y graba bloques de datos de la base de datos siempre que el usuario la edite o consulte. El tamaño de la memoria caché del búfer es controlado por el parámetro DB_CACHE_SIZE.

A diferencia del grupo compartido y el búfer del registro, no se recomienda un tamaño mínimo para la memoria caché del búfer. Como su objetivo de ajustar el tamaño de la memoria caché del búfer es mantener la cantidad máxima posible de la base de datos en la memoria, intente asignar la memoria restante a la memoria caché del búfer tras contemplar las necesidades del resto del sistema. Para calcularlo, siga estos pasos:

1. Determine cuánta memoria física de acceso aleatorio (RAM) tiene el servidor.
2. Multiplique este número por 0,66 para determinar el tamaño de destino del SGA.
3. Reste los parámetros SHARED_POOL_SIZE y LOG_BUFFER para devolver la cantidad de memoria disponible a la memoria caché del búfer.
4. Reduzca este número a un 10 por ciento para contemplar el uso de la memoria interna de Oracle.
5. Divídalo por el tamaño del bloque de la base de datos para determinar el ajuste DB_BLOCK_BUFFERS.

Por ejemplo:

memory available to SGA = physical RAM * 2/3  memory available to buffer cache = (memory available to SGA - (shared_pool_size + log_buffer)) * 0.9  db_block_buffers   = memory available to buffer cache / db_block_size

PGA_AGGREGATE_TARGET

Asigne espacio para el área global privada (PGA) de los procesos del servidor de Oracle. Este espacio se utiliza normalmente como un búfer temporal para clasificar y fusionar datos durante una unión de tablas. Establezca el parámetro WORKAREA_SIZE_POLICY en AUTO, luego establezca inicialmente el parámetro PGA_AGGREGATE_TARGET en el total de memoria RAM física multiplicado por 0,16. En cuanto la aplicación se haya utilizado durante cierto tiempo, ajuste el parámetro PGA_AGGREGATE_TARGET según el procedimiento descrito en Oracle Performance Tuning Guide and Reference.

workarea_size_policy = auto pga_aggregate_target = <total physical RAM * 0.16)

Nota:

Oracle utiliza el parámetro PGA_AGGREGATE_TARGET para asignar memoria para clasificar sólo si el parámetro WORKSPACE_POLICY está establecido en AUTO. Si no lo está, Oracle utilizará el método manual anterior de gestionar el área de clasificación, el cual incluye establecer los parámetros SORT_AREA_SIZE y HASH_AREA_SIZE.

Utilice la gestión de área de trabajo automática

Oracle puede gestionar memoria privada para los procesos del servidor que mantiene sesiones de usuario de forma automática, de la misma forma que gestiona la memoria compartida con la gestión de la memoria compartida automática (ASMM). Las áreas de trabajo de SQL para clasificar, ejecutar algoritmos hash y procesar índices de mapas de bits pueden asignarse dinámicamente por Oracle a partir de un enorme grupo de memoria disponible para todos los PGA en lugar de configurarse a un tamaño fijo por el administrador de la base de datos (DBA). Para habilitar la gestión del área de trabajo automática, establezca el parámetro WORKAREA_SIZE_POLICY en AUTO. A continuación, configure la cantidad total de memoria disponible en todos los PGA especificando el tamaño como el valor del parámetro PGA_AGGREGATE_TARGET. Por defecto, Oracle configurará el tamaño total del PGA a un 20 por ciento del tamaño del SGA. Éste es un buen punto de partida, pese a que el PGA deberá ajustarse basándose en el tipo de trabajo realizado por los procesos del servidor, y no estrictamente en relación al tamaño del SGA. En cuanto su base de datos se ejecute en una carga normal, podrá controlar y ajustar el tamaño del PGA de destino basándose en la carga de trabajo real. Para obtener más información sobre este proceso, consulte Oracle Database Performance Tuning Guide.

Utilice la gestión de memoria compartida automática

Si está utilizando Oracle 10g, tiene la posibilidad de configurar un tamaño total para el SGA y permitir que Oracle gestione automáticamente la distribución de la memoria entre sus grupos constituyentes. Esto es ASMM y se invoca con el parámetro SGA_TARGET. Además de simplificar el trabajo del DBA relativo a la configuración individual de grupos, utilizar ASMM permite que Oracle controle de forma continua las demandas de cada grupo y ajuste dinámicamente sus tamaños mientras la instancia está ejecutándose. No sería práctico que un DBA realizara este mismo nivel de supervisión de manera constante. Puede ofrecer instrucciones para ASMM configurando el parámetro SGA_TARGET para que especifique el tamaño total del SGA así como uno o más parámetros para grupos individuales. Cuando se especifican tanto SGA_TARGET como un tamaño de grupo, Oracle interpreta el tamaño de grupo como un mínimo que ASMM mantendrá para esa memoria caché.

Teniendo en cuenta la importancia del grupo compartido en el rendimiento de la geodatabase, al utilizar ASMM, establezca el tamaño mínimo del grupo compartido (el parámetro de inicialización SHARED_POOL_SIZE) en un mínimo de 128 MB, tal y como se recomienda arriba, además de establecer SGA_TARGET.

Nota:

Para utilizar el área de trabajo automática y la gestión automática de la memoria compartida, el parámetro STATISTICS_LEVEL deberá establecerse en TYPICAL (el valor por defecto que se recomienda) o ALL.

Otros cambios

Aunque no es un parámetro de inicialización, la directiva del plan del gestor de recursos de la base de datos UNDO_POOL puede establecerse para permitir que un grupo de consumidores del usuario sde cuente con un amplio espacio de deshacer para operaciones de compresión.

Para utilizarlo, deberá configurar un grupo de consumidores para el usuario sde y modificar la directiva de plan UNDO_POOL para permitir un grupo ilimitado para deshacer para este grupo de consumidores.

UNDO_POOL identifica la cantidad total de espacio de deshacer que los miembros de un grupo de recursos, de forma conjunta, pueden asignar a la vez.

Al utilizar un geodatabase para editar versionadas, deberá realizar periódicamente una operación de compresión para limpiar la información antigua y simplificar el contenido de la geodatabase. Si ha tenido lugar un gran número de ediciones desde la última operación de compresión, el nuevo procedimiento de compresión puede crear grandes transacciones que requieran una enorme cantidad de espacio de deshacer. Si UNDO_POOL está establecido demasiado bajo, puede fallar la operación de compresión y puede originarse un bajo rendimiento. Si es posible, establezca el grupo ilimitado de deshacer para el grupo de consumidores del usuario sde. De lo contrario, deberá controlar el tamaño de las transacciones de compresión y elegir un tamaño de grupo de deshacer lo suficientemente grande.