Cuando se habilita la variable de registro DB2_FORCE_FCM_BP hay unos pocos segmentos |de memoria compartidos disponibles para otros usos, particularmente para agrupaciones de |almacenamientos internos de base de datos. La habilitación de la variable de registro DB2_FORCE_FCM_BP de este modo reduce |el tamaño máximo de las agrupaciones de almacenamientos intermedios de base de datos. Tenga en cuenta |que debido al gran número de segmentos de memoria compartidos disponibles |en un entorno de 64 bits, esta reducción en el número de segmentos de memoria compartidos |debe ser un hecho sólo en entornos de 32 bits.
| | |Cuando una tabla se crea por primera vez, las estadísticas de catálogo de sistema se establecen |en -1 para indicar que la tabla no tiene estadísticas. Hasta que se reúnen las estadísticas, |DB2 UDB utiliza los valores por omisión para la optimización y compilación de sentencias SQL. | Al actualizar la tabla o el índice las estadísticas podrían fallar si los nuevos valores |son inconsistentes con los valores por omisión. Por esto, ejecute el mandato runstats en una tabla o |índice antes de actualizar manualmente las estadísticas para cualquiera.
| | |El mensaje de error SQL1169N de SQL tiene un nuevo código de razón 5 para indicar que una columna |de una tabla de explicación es demasiado pequeña.
|El texto siguiente es una actualización de la publicación Administration |Guide: Performance, Chapter 6. Understanding the SQL compiler.
|Se puede utilizar la transferencia de MDC aunque el índice RID sea parte del |plan de optimización independientemente de la presencia de una cláusula WHERE en la |sentencia DELETE. |Como resultado, cuando se listan las condiciones que se deben cumplir para permitir |la transferencia y el uso de una manera más eficiente para suprimir filas, la condición |que un "índice RID no fue elegido por el optimizador para buscar las filas a suprimir, |a menos que no haya la cláusula WHERE en la sentencia DELETE" debe ser suprimida.
|Además, puede indicar si la transferencia de MDC está en vigor porque la |salida db2expln muestra la frase "Cell Delete". | Tenga en cuenta que db2exfmt no muestra esta información.
|El texto siguiente es una actualización para el Apéndice A. |Variables de entorno y registro de DB2:
|La descripción de DB2_MDC_ROLLOUT debe cambiarse tal que la condición |que un "índice RID no fue elegido por el optimizador para buscar las filas |a suprimir, a menos no haya la cláusula WHERE en la sentencia DELETE" debe |suprimirse de la lista.
| | |Si actualiza los valores del parámetro de |configuración newlogpath, mirrorpath o overflowlogpath en un entorno de DB2 UDB, el número de nodo se añadirá al nombre de |vía de acceso independientemente del número de nodos en el sistema. Esto se aplica tanto a los sistemas de varias particiones como a sistemas de partición |única en un entorno DB2 UDB Enterprise Server Edition.
| | |El valor por omisión para DB2_COLLECT_TS_REC_INFO es ON. En DB2 UDB V 8.1 FixPak 7, el valor por omisión para la variable de registro |DB2_COLLECT_TS_REC_INFO se cambió a ON. La documentación |actual especifica incorrectamente el valor por omisión para esta variable como OFF.
Una instancia de Governor consta de un programa de utilidad frontal y uno o más daemons. Cada instancia de Governor que el usuario inicia es específica de una instancia del gestor de bases de datos. Por omisión, cuando el usuario inicia el programa Governor, se inicia un daemon de Governor en cada partición de una base de datos particionada. Sin embargo, el usuario puede especificar que se inicie un daemon en una partición individual que desee supervisar.
Cada daemon de Governor recoge información sobre las aplicaciones que se ejecutan para la base de datos. El daemon governor entonces comprueba esta información con las reglas que especifique en el archivo de configuración de governor para esta base de datos.
Cuando considere la posibilidad de utilizar la reorganización de tabla in situ (en lugar de la reorganización de tabla clásica), tenga en cuenta que la reorganización de tabla in situ necesita más espacio para las anotaciones cronológicas.
Debido a que la reorganización de tabla in situ registra anotaciones sobre sus actividades para que sea posible una recuperación después de un error inesperado, esta reorganización necesita más espacio para anotaciones cronológicas que la reorganización clásica.
La reorganización in situ puede llegar a necesitar un espacio para anotaciones cronológicas que sea varias veces el tamaño de la tabla reorganizada. La cantidad de espacio necesario depende del número de filas que se trasladen y del número y tamaño de los índices de la tabla.
Recomendación: elija la reorganización de tabla in situ para las operaciones que se ejecutan durante las 24 horas del día, los 7 días de la semana, con unos intervalos mínimos de mantenimiento.
La reorganización de tabla en línea de una tabla DMS permite iniciar una operación de copia de seguridad en línea de un espacio de tabla donde reside la tabla mientras tiene lugar la reorganización. Se pueden producir esperas de bloqueo en la operación de reorganización durante la fase de truncamiento.
Consulte las descripciones de la sintaxis de REORG TABLE para obtener información detallada sobre la ejecución de estos métodos de reorganización de tabla.
En AIX(R) 5L de 64 bits, la variable del registro DB2_LARGE_PAGE_MEM ahora admite la utilización de la palabra clave FCM.
Por omisión, en AIX(R) 5L de 64 bits, la memoria FCM está en el conjunto de memoria de DBMS. Sin embargo, cuando la variable del registro DB2_FORCE_FCM_BP está habilitada, la memoria de FCM reside en su propio conjunto de memoria. En AIX 5L de 64 bits, DB2_LARGE_PAGE_MEM admite la especificación del conjunto de memoria de DBMS. Cuando la memoria de FCM reside en el conjunto de memoria de DBMS, y está habilitado el soporte para páginas grandes para ese conjunto de memoria, la memoria de FCM estará en páginas grandes. Cuando la memoria de FCM reside en su propio conjunto de memoria, se debe añadir la palabra clave FCM al valor de la variable del registro DB2_LARGE_PAGE_MEM para habilitar las páginas grandes para la memoria de FCM.
A partir de DB2 Universal Database(TM) (UDB) Versión 8.2.2 (equivalente a la Versión 8.1 Fixpak 9), el archivo de configuración especificado por la variable del registro DB2_RESOURCE_POLICY acepta un elemento SCHEDULING_POLICY. El elemento SCHEDULING_POLICY se puede utilizar en algunas plataformas para seleccionar:
Las variables del registro DB2PRIORITIES y DB2NTPRICLASS se pueden utilizar por separado para controlar la política de planificación del sistema operativo y establecer prioridades para agentes de DB2.
Sin embargo, la especificación de un elemento SCHEDULING_POLICY en el archivo de configuración de la política de recursos proporciona un único lugar para especificar tanto la política de planificación como las prioridades del agente asociado.
Selección de la política de planificación AIX SCHED_FIFO2 con un aumento de prioridad para los procesos del escritor y lector del registro de anotaciones de DB2:
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE>
<PRIORITY_VALUE>60</PRIORITY_VALUE>
<EDU_PRIORITY>
<EDU_NAME>db2loggr</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
<EDU_PRIORITY>
<EDU_NAME>db2loggw</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Sustitución para DB2NTPRICLASS=H en Windows.
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Se han añadido las variables de entorno del sistema DB2_MAPPED_BASE y DB2DBMSADDR al FixPak 8.
La utilización de estas variables del registro solamente se recomienda a usuarios experimentados.
DB2 UDB intenta volver a ubicar las bibliotecas compartidas en la dirección virtual 0x10000000 si esta variable no está establecida.
La variable del registro también se puede establecer en cualquier dirección virtual (en hex) dentro del rango del espacio de direcciones de 31 y 32 bits.
db2set DB2_MAPPED_BASE=
El mensaje siguiente puede aparecer varias veces en el archivo db2diag.log debido a que es necesario efectuar este cambio una vez para cada nodo lógico:
ADM0506I DB2 ha actualizado automáticamente el parámetro de kernel "mapped_base" de "0x40000000(hex) 1073741824(dec)" al valor recomendado "0x10000000(hex) 268435456(dec)".
Este mensaje sólo aparecerá si se establece satisfactoriamente la variable del registro e incluirá la dirección en la que se reubican las bibliotecas compartidas.
db2set DB2DBMSADDR=
Esta variable se puede establecer junto con DB2_MAPPED_BASE o sola para ajustar correctamente el diseño del espacio de direcciones de procesos de DB2 UDB. Esta variable cambia la ubicación de la memoria compartida de la instancia desde su ubicación actual en la dirección virtual 0x20000000 hasta el nuevo valor proporcionado.
La variable del registro DB2TCP_CLIENT_RCVTIMEOUT se ha añadido en la Versión 8.2.
La variable de rendimiento DB2_LARGE_PAGE_MEM se ha añadido en la Versión 8.2.
| Nombre de la variable | Sistemas operativos | Valores |
|---|---|---|
| Descripción | ||
| DB2_LARGE_PAGE_MEM |
Sólo AIX 5.x de 64 bits Linux |
Valor por omisión=NULL
Utilice * para indicar que todas las regiones de memoria aplicables deben utilizar memoria de página grande o una lista separada por comas de regiones de memoria específicas que deben utilizar memoria de página grande. Las regiones disponibles varían por sistema operativo. En AIX 5.x de 64 bits, se pueden especificar las siguientes regiones: DB, DBMS o PRIVATE. En Linux, se puede especificar la siguiente región: DB. |
|
La memoria de página grande sólo recibe soporte para DB2 Universal Database (UDB) para AIX 5L, Edición de 64 bits, y DB2 UDB para Linux. La variable del registro DB2_LARGE_PAGE_MEM se utiliza para habilitar el soporte de páginas grandes cuando se ejecuta en AIX 5.x o en cualquier arquitectura Linux con el soporte de kernel adecuado. Esta variable del registro deja obsoleta la variable del registro DB2_LGPAGE_BP, que sólo se puede utilizar para habilitar memoria de páginas grandes para la región de memoria compartida de base de datos. Ahora esto se puede habilitar estableciendo DB2_LARGE_PAGE_MEM=DB. Cualquier documentación que mencione la habilitación de páginas grandes con la variable del registro DB2_LGPAGE_BP se puede interpretar como sinónimo de establecer DB2_LARGE_PAGE_MEM=DB. El uso de páginas grandes está principalmente destinado a ofrecer mejoras en el rendimiento para aplicaciones de cálculo de alto rendimiento. Las aplicaciones con gran cantidad de acceso a memoria que utilizan grandes cantidades de memoria virtual pueden mejorar el rendimiento utilizando páginas grandes. Para permitir que DB2 UDB utilice páginas grandes, primero debe configurar el sistema operativo para que utilice páginas grandes. La habilitación de páginas grandes privadas aumentará el uso de memoria de DB2 UDB de forma significativa, ya que cada agente de DB2 UDB consumirá al menos 1 página grande (16 MB) de memoria física. Para habilitar páginas grandes para memoria privada de agentes en DB2 UDB para AIX de 64 bits (el valor DB2_LARGE_PAGE_MEM=PRIVATE), se deben cumplir las siguientes condiciones, además de configurar páginas grandes en el sistema operativo:
En DB2 UDB para AIX de 64 bits, la habilitación de esta variable disminuye el tamaño de la memoria de base de datos de copia de seguridad del segmento de memoria compartida al requisito mínimo. El comportamiento por omisión es crear un segmento de 64 GB: consulte el parámetro de configuración de base de datos referente al tamaño de la memoria compartida de la base de datos (database_memory) para obtener más detalles. Esto evita inmovilizar más memoria compartida en RAM de la que es probable que se vaya a utilizar. Al establecer esta variable, se limitará la posibilidad de aumentar dinámicamente la configuración general de memoria compartida de base de datos (por ejemplo, para aumentar el tamaño de las agrupaciones de almacenamientos intermedios). En Linux, existe un requisito adicional para la disponibilidad de la biblioteca libcap.so. Esta biblioteca debe estar instalada para que esta opción funcione. Si esta opción está activada, y la biblioteca no está en el sistema, DB2 UDB inhabilitará las páginas grandes de kernel y continuará funcionando como anteriormente. En Linux, para verificar si hay páginas grandes de kernel disponibles, emita el mandato siguiente: cat /proc/meminfo Si están disponibles, deben aparecer las tres líneas siguientes (con distintos números, en función de la cantidad de memoria configurada en la máquina): HugePages_Total: 200
HugePages_Free: 200
Hugepagesize: 16384 KB
Si no ve estas líneas, o si HugePages_Total es 0, hay que configurar el sistema operativo o el kernel. |
||
La siguiente actualización se aplica al tema "SQL compiler variables" del apéndice A "DB2 DB2 registry and environment variables" en el manual Administration Guide: Performance:
Cuando una o ambas variables de compilador de DB2, DB2_MINIMIZE_LISTPREFETCH y DB2_INLIST_TO_NLJN, están establecidas en ON (activada), permanecen activas incluso si se ha especificado REOPT(ONCE).
A continuación se proporcionan las actualizaciones que se han efectuado en la documentación sobre parámetros de configuración:
El parámetro de configuración del gestor de bases de datos Tipo de autentificación (authentication) también acepta los valores siguientes:
El servidor acepta esquemas de autentificación de SERVIDOR cifrado y el cifrado de datos de usuario. La autentificación funciona del mismo modo que SERVER_ENCRYPT.
Los siguientes datos de usuario se cifran cuando se utiliza este tipo de autentificación:
El servidor acepta esquemas de autentificación de SERVIDOR cifrado y el cifrado de datos de usuario. Además, este tipo de autentificación permite la compatibilidad con productos anteriores que no dan soporte al tipo de autentificación DATA_ENCRYPT. Está permitido que estos productos se conecten con el tipo de autentificación SERVER_ENCRYPT y sin cifrar datos de usuario. Los productos que dan soporte al nuevo tipo de autentificación deben utilizarlo. Este tipo de autentificación sólo es válido en el archivo de configuración del gestor de bases de datos del servidor y no es válido cuando se utiliza en el mandato CATALOG DATABASE.
A partir de DB2 Universal Database Versión 8.2, el valor por omisión del parámetro de configuración del gestor de bases de datos Política de impacto de instancia (util_impact_lim) cambia de 100 a 10.
Los siguientes parámetros de configuración del gestor de bases de datos pueden aceptar nombres de grupo de 30 bytes (o menos) en todas las plataformas:
La tabla del tema "Resumen de los parámetros de configuración del gestor de bases de datos" contiene tipos de datos incorrectos para estos parámetros de configuración del gestor de bases de datos. El valor correcto en todos los casos es char(30).
El tamaño máximo para el parámetro de configuración Base de datos de tamaño de segmento de memoria de almacenamiento ampliado (estore_seg_size) en plataformas basadas en Windows es 16 777 216.
El límite superior correcto del parámetro de configuración de base de datos Valor de tiempo de espera excedido de HADR (hadr_timeout) es 4 294 967 295.
La documentación para el parámetro de configuración de base de datos Almacenamiento máximo para lista de bloqueos (locklist) indica que el valor máximo para servidores de Windows de 64 bits y de 32 bits que solamente atienden a clientes locales es de 0 000. Este valor es incorrecto y debería ser 524 288.
El rango de valores para el parámetro de configuración de base de datos Número de copias de seguridad de base de datos (num_db_backups) es incorrecto. El rango correcto es 0 - 32 767.
Después de migrar a DB2 Universal Database (UDB) Versión 8.2 desde la Versión 8.1, DB2 UDB utiliza un nuevo archivo de parámetros de configuración de base de datos de 16 KB denominado SQLDBCONF. (En la Versión 8.1, el archivo de parámetros de configuración de base de datos tan solo era de 4 KB y se denominaba SQLDBCON).
En la Versión 8.1, la variable del registro DB2_HASH_JOIN está establecida en ON (activada) por omisión.
La variable de unión de generación aleatoria debería utilizarse, pero necesita ajustarse para obtener el máximo rendimiento.
El máximo rendimiento de unión de generación aleatoria se obtiene si se pueden evitar bucles de generación aleatoria y desbordamientos de disco. Para ajustar el rendimiento de unión de generación aleatoria, calcule la cantidad máxima de memoria disponible para el parámetro sheapthres y, a continuación, ajuste el parámetro sortheap. Aumente su valor hasta que evite tantos bucles de generación aleatoria y desbordamientos como sea posible, pero sin alcanzar el límite que especifique el parámetro sheapthres.
Para obtener más información, consulte el tema "Métodos de unión" en el manual Administration Guide: Performance.
La funcionalidad que antes se conseguía mediante DB2NTNOCACHE se puede conseguir a nivel de espacio de tabla especificando la cláusula NO FILE SYSTEM CACHING en la sentencia CREATE TABLESPACE o ALTER TABLESPACE. Consulte el manual Consulta de SQL para ver detalles sobre su uso. La variable del registro DB2NTNOCACHE se eliminará en un futuro release.
Las tablas de explicación pueden ser comunes a más de un usuario. Sin embargo, las tablas de explicación se pueden definir para un usuario, y se pueden definir alias para cada usuario adicional utilizando el mismo nombre para apuntar a las tablas definidas. Como alternativa, las tablas de explicación se pueden definir bajo el esquema SYSTOOLS. El recurso Explain tomará por omisión el esquema SYSTOOLS si no se encuentra ninguna otra tabla de explicación o alias bajo el ID de sesión del usuario para SQL dinámico o el ID de autorización de sentencia para SQL dinámico. Cada usuario que comparta las tablas de explicación comunes debe insertar permiso sobre dichas tablas. El permiso de lectura para las tablas de explicación comunes también se debe limitar, generalmente a los usuarios que analizan la información de explicación.
Se capturan datos de explicación si así lo solicita al compilar la sentencia de SQL. Tenga en cuenta cómo piensa utilizar la información capturada al solicitar datos de explicación.
La información de tablas de explicación se captura en cualquiera de los siguientes casos:
El parámetro de información de clasificación sólo se puede visualizar utilizando la API db2CfgGet. No se puede visualizar mediante el procesador de línea de mandatos o el Centro de control.
Este parámetro proporciona 260 bytes de información de clasificación de la base de datos. Los primeros 256 bytes especifican la secuencia de clasificación de la base de datos, donde el byte "n" contiene el peso de clasificación del punto de código cuya representación decimal subyacente es "n" en la página de códigos de la base de datos.
Los últimos 4 bytes contienen información interna sobre el tipo de secuencia de clasificación. Los últimos 4 de collate_info constituyen un entero. El entero es sensible al orden endian de la plataforma. Los valores posibles son:
Si utiliza esta información de tipos internos, debe tener en cuenta la inversión de bytes cuando recupere información para una base de datos en otra plataforma.
Puede especificar la secuencia de clasificación en el momento de la creación de la base de datos.
A partir de DB2 Universal Database (UDB) Versión 8.2, se puede utilizar el tamaño de captación previa AUTOMATIC (automático) para un espacio de tabla. DB2 UDB actualiza automáticamente el tamaño de captación previa cuando cambia el número de contenedores para el espacio de tabla.
La sintaxis de la variable del registro DB2_PARALLEL_IO se amplía para reconocer contenedores con distintas características de paralelismo de E/S. Mediante la sintaxis ampliada, los contenedores para espacios de tabla diferentes pueden tener características de paralelismo de E/S diferentes. La característica de paralelismo de E/S de cada espacio de tabla se utiliza cuando se especifica un tamaño de captación previa AUTOMATIC (automático) para el espacio de tabla. Si la variable del registro DB2_PARALLEL_IO está habilitada pero no se utiliza la sintaxis ampliada que identifica las características de paralelismo de E/S para los espacios de tabla, se considera que se trata de un nivel de paralelismo por omisión. El nivel por omisión es RAID 5 (6+1).
La información del tamaño de captación previa que utiliza el optimizador sólo se renueva cuando se emite una sentencia ALTER TABLESPACE que cambia el tamaño de captación previa de un espacio de tabla o que cambia el número de contenedores (utilizando ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET). Si el número de discos físicos para los valores de registro de contenedor cambia, debe emitirse una sentencia ALTER TABLESPACE <nombre espacio tablas> PREFETCHSIZE AUTOMATIC para renovar la información del optimizador (a menos que ya se haya emitido una sentencia ALTER TABLESPACE que renueve la información del optimizador).
Si un espacio de tabla se redirige o restaura para utilizar un número diferente de contenedores, renueve la información del optimizador emitiendo una sentencia ALTER TABLESPACE <nombre espacio tablas> PREFETCHSIZE AUTOMATIC. Si existen varios conjuntos de bandas dentro de un espacio de tabla, se utiliza el número máximo de contenedores entre los conjuntos de bandas para calcular el tamaño de captación previa. Si el tamaño de captación previa calculado supera el tamaño máximo (32 767 páginas), se utiliza como tamaño de captación previa el múltiplo más grande del número de contenedores que sea inferior al máximo.
En un entorno DB2 UDB Enterprise Server Edition, si un espacio de tabla utiliza un tamaño de captación previa AUTOMATIC (automático), el tamaño de captación previa puede ser diferente en diferentes particiones de bases de datos. Esta situación puede producirse dado que diferentes particiones de bases de datos pueden utilizar diferentes números de contenedores para calcular el tamaño de captación previa. Para generar el plan de acceso de consulta, el optimizador utiliza el tamaño de captación previa de la primera partición de un grupo de particiones de bases de datos.
[ Principio de página |Página anterior | Página siguiente | Contenido ]