motor:Informix Dynamic Server 2000 Version 9.21.UC3
sistema: Debian 4.0
guaraní versión 2.6.2
operaciones activas en 3w reinscripción anual, inscripción a cursadas, inscripción a exámenes
root dbspace con dos chunks de 256000 páginas (páginas de 2 kb).
el valor del parámetro DBSPACETEMP está asignado a un dbspace temporal
el problema es que con las operaciones de inscripción a cursada y a exámenes se llenan los dos chunks del root dbspace y mirando un poco cuales eran los procesos llegamos a que son los los sp sp_matInscCurAlu y sp_matinscexamalu que en algún lugar crean tablas temporales en el root dbspace pero no encuentro donde puede ser. Los sp crean explíctamente tablas con la opción WITH NO LOG, por lo que supongo que son las consultas a las vistas de historia académica y sga_cursadas.
Alguna idea para tratar de encontrar el inconveniente? nunca nos pasó antes. Es muy poco el espacio asignado al root?
Una cosa es la teoría y otra la práctica.
Agregale mas chunks al root. Si no tenes problemas de espacio en disco metele dos o tres gigas mas.
Varias veces pasó que por mas que tengas un dbspace temporal, las tablas temporales las crees con with no log, empieza a trabajar en el root dbspace. Nunca supe porque.
buscando encontré esto y me gustaría si nos pueden ampliar como lo solucionaron.
Tenemos un problema parecido y en principio hicimos lo mismo. Agregamos Chunks y se siguen llenando. El problema es principalmente con algunos reportes “Pesados”.
Una cosa que nos llamo la atención es que se llenan los Chunks de Rootdbs mientras que el de Tempdbs permanece vacio. Eso no desorientó un poco ya que pensabamos agregarle espacio temporal pero nos parece que no va a servir para nada.
Les adjunto nuestro ONCONFIG y el resultado de un ONSTAT - d y ONSTAT -u.
Les adjunto también un error que nos da con algunos reportes y no siempre. Les aclaro que hasta hace poco (acabamos de atravesar un cambio de planes con generación de muchas equivalencias) los reportes funcionaban bien, algunos tardaban un poco pero nada más.
Quizás sería interesante que Damián comente donde estaba el problema en su personalización, para ver si no es algo similar.
Nosotros tuvimos problemas similares en el 2006 cuando estabamos migrando datos en una instalación. Si no bajabamos unos triggers (ya no recuerdo cuales), era como que se llenaba el rootdbspace, por SP que creaban tablas temporales y no las dropeaban.
Damián: recordarás donde estab el problema de ustedes?
Hola, la verdad no me acuerdo la consulta a la vista historia académica que daba este comportamiento, hay que hacer un análisis de la salida del analizador de consultas para tratar de descubrir por donde viene la mano.
Se toma la consulta “pesada”, se agrega la ejecución de
SET EXPLAIN ON;
luego se ejecuta la consulta y se revisa lo que escribe en el archivo sqlexplain.out hay que tratar de evitar las consultas mas “costosas” y aquellas que hacen “sequential scan” en alguna tabla grande.
Espero que ayude
