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.
Cada vez que se inicia una instancia de Oracle, Oracle lee los parámetros de inicialización del archivo init.ora o del archivo de parámetros del servidor, spfile.ora. Ambos archivos definen las características de la instancia pero se gestionan de forma distinta.
El archivo init.ora se encuentra en el directorio o la 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.
A continuación se presentan algunas sugerencias para configurar parámetros al implementar una gran geodatabase muy utilizada en Oracle:
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 la documentación de Oracle 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 predeterminado es 300. Si la sesión intenta abrir un nuevo cursor pero ya tiene abierto el número máximo 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 lugar de eso, desea calcular el número posible de cursores que se han abierto en una sesión, la siguiente fórmula, basada en el modelo de datos de su organización, se puede utilizar como orientación. Recuerde que ArcGIS abrirá el 80% del número especificado de cursores abiertos, lo que permite que los procesos de Oracle usen el 20% restante.
- Diversos cursores de la administración de datos de ArcGIS (20) +
- Diversos bloques PL/SQL anónimos (20) +
- Consultas espaciales: pueden llegar hasta 6 por clase de entidad +
- Consultas de archivo de registro (11) +
- Consultas varias utilizadas al editar tablas versionadas—12 por capa o tabla versionadas
Por tanto, si va a editar 10 capas en ArcMap, puede tener abiertos 231 cursores (20 + 20 + 60 + 11 + 120 = 231). En este caso, la configuración predeterminada de 300 OPEN_CURSORS es suficiente, ya que ArcGIS admitirá 240 cursores abiertos con este ajuste. Sin embargo, si se le acaban los cursores con frecuencia, puede aumentar el valor del parámetro OPEN_CURSORS en incrementos de 50 o 100.
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 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 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 caché, aumente el valor de este parámetro a 50.
SESSIONS
La geodatabase está configurada para permitir conexiones ilimitadas a ella. Si espera que haya un gran número de conexiones simultáneas a la geodatabase, es posible que necesite modificar el parámetro SESSIONS de Oracle para dar cabida a estas.
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.
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. Asegúrese de que el parámetro PROCESSES sea como mínimo tan grande como el número de conexiones simultáneas de geodatabase que anticipa, más 25 para un conjunto típico de procesos de fondo de Oracle.
Parámetro que afecta a las estadísticas de Oracle
OPTIMIZER_MODE
Mantenga el valor predeterminado (all_rows) del parámetro OPTIMIZER_MODE de Oracle. 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. En general, no se debe asignar más del 70 por ciento de la memoria física del servidor a las bases de datos del servidor.
SHARED_POOL_SIZE
El grupo compartido es un componente del Área Global del Sistema de Oracle (SGA) que mantiene tanto la caché del diccionario de datos como la caché de la biblioteca. La caché del diccionario de datos mantiene información acerca de los objetos de datos, espacio libre y privilegios. La 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 caché de la biblioteca, será lo suficientemente grande como para mantener la caché del diccionario de datos.
Las geodatabases pueden aprovecharse de un grupo compartido mayor que algunas otras aplicaciones de Oracle. ArcGIS mantiene una 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 parámetro SHARED_POOL_SIZE controla el tamaño del grupo compartido. 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 caché del búfer para dar cabida a un grupo compartido mayor.
Utilizar la administración automática del área de trabajo y la memoria compartida
Debería aprovechar los mecanismos que aporta Oracle para administrar automáticamente el área de trabajo y la asignación de memoria. Consulte la información sobre cómo se configura la administración del área de trabajo y la memoria en la Guía del administrador de base de datos Oracle correspondiente a la versión de Oracle que utilice.
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.