PDQ combinado con OLTP

Hola: Antes que nada, buenos días a todos los miembros; solo quería preguntar si alguien ha combinado PDQ con OLTP en su base de datos. Nuestra base de datos es mayormente OLTP, con un proceso de procesamiento por lotes que se ejecuta todos los días hábiles desde las 12 de la medianoche hasta las 3 AM. Me pregunto si puedo usar PDQ para el proceso por lotes y que el resto de la memoria se asigne a la caché de búfer para fines de OLTP. ¿Funcionaría esto? ¿Mejoraría el proceso por lotes? Hasta ahora no hay PDQ ejecutándose en el servidor; la memoria total es de 32 GB, con 16 GB asignados al búfer, 4 GB en SHMVIRTSIZE y 2 MB para DS_TOTAL_MEMORY. Tengo pensado aumentar DS_TOTAL_MEMORY inicialmente al 50 % de SHMVIRTSIZE en nuestro servidor de staging para probar si el proceso mejora. Si es así, ¿cómo puedo indicarle a las consultas que usen PDQ? He leído en algún lado que PDQPRIORITY ya no funciona después de la versión 7.1, ¿es cierto?

Hola Lester: Sí, puedes usar PDQ en las últimas versiones; no estoy seguro de qué es lo que habrás leído. El primer paso sería determinar si tu proceso por lotes se beneficiará del procesamiento paralelo examinando los planes de consulta. Un "set explain on" o "set explain on avoid_execute" lo determinaría, y tendrías que buscar la palabra clave "parallel" en el plan de consulta. Si no tienes tablas particionadas (fragmentadas), esto no es muy probable. Tu mensaje se centra en el aspecto de la gestión de memoria. Normalmente, las ordenaciones grandes (order by, group by, distinct, etc.) se benefician de más memoria. ¿Observas uso de dbspaces temporales mientras se ejecuta la consulta? Si tienes la versión 12.10.xC8 o superior, puedes monitorizar el uso de espacio temporal en tiempo real con: SELECT i.sid, hex(i.flags) flags, hex(i.partnum) partition, trim(n.dbsname) || ":" || trim(n.owner) || ":" || trim(n.tabname) table, i.nptotal allocated_pages FROM sysmaster:systabnames n, sysmaster:sysptnhdr i WHERE (sysmaster:bitval(i.flags, "0x0020") = 1) AND i.partnum = n.partnum; Si no ves uso de espacio temporal, es poco probable que algún ajuste de memoria ayude. Puede que simplemente sea una consulta lenta. Si no vas a obtener ningún beneficio del procesamiento paralelo, ¿has considerado ajustar DS_NONPDQ_QUERY_MEM como alternativa al uso de PDQ? También tendrías que aumentar DS_TOTAL_MEMORY. Ambos parámetros son configurables dinámicamente. https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.adref.doc/i ds_adr_0064.htm Ben.

Gracias por la respuesta BENJAMIN THOMPSON lamentablemente, según la verificación, tenemos 1 tabla fragmentada, pero no está incluida en el proceso por lotes =( ¿esto significa que PDQ probablemente no sería aplicable? DS_NONPDQ_QUERY_MEM es el equivalente para las consultas que no usan PDQ, ¿correcto? ¿forma parte del SHMTOTAL y es distinto de la asignación de espacio de BUFFER? Según lo que he revisado, el valor de DS_NONPDQ_QUERY_MEM es 512 KB; dada la siguiente asignación de memoria, ¿cuánto puedo ajustar para la consulta NONPDQ? ¿Cómo asigna Informix la memoria de DS_NONPDQ_QUERY_MEM a cada consulta? Además, en cuanto a la consulta de tempdb, tendré que programarla para verificar si se utiliza durante el procesamiento por lotes. IBM Informix Dynamic Server Version 12.10.FC8 memoria total: 32 GB 16 GB asignados para Buffer 4 GB en SHMVIRTSIZE 2 MB para DS_TOTAL_MEMORY 512 KB para DS_NONPDQ_QUERY_MEM

Necesitas revisar el plan de ejecución (explain plan) para ver si te beneficiarías del procesamiento en paralelo. Creo que si configuras PDQ, aún puedes beneficiarte del acceso al gestor de concesiones de memoria (memory grant manager) incluso sin una consulta paralela. Puedes comprobarlo con "onstat -g mgm" mientras se ejecuta tu consulta. 2 MB para DS_TOTAL_MEMORY realmente no es mucho. DS_TOTAL_MEMORY forma parte de SHMVIRTSIZE, pero creo que es un límite más que un pool. SHMTOTAL es un límite impuesto al tamaño de SHMVIRTSIZE. ¿Monitorizas el uso de SHMVIRTSIZE en tu sistema? La forma más básica es usando "onstat -g seg". IBM no documenta muy bien cómo funcionan las asignaciones de memoria, presumiblemente como parte de la política de no documentar ciertos funcionamientos internos que podrían estar sujetos a cambios. Lo que sí puedo decir es que tengo DS_NONPDQ_QUERY_MEM configurado en 16 MB en un sistema y hay muchas sesiones que utilizan bastante menos de 16 MB de memoria. Creo que esto solo se asignaría para realizar una ordenación. ¡Me encantaría que alguien con mejor conocimiento del funcionamiento del servidor aportara su opinión! Por cierto, este foro se está trasladando a: https://community.ibm.com/community/user/hybriddatamanagement/communities/commun ity-home?CommunityKey=cf5a1f39-c21f-4bc4-9ec2-7ca108f0a365 Ben.