ixtempuse news / novidades sobre o ixtempuse

Some slight changes in ixtempuse script (original version here: http://informix-technology.blogspot.com/2016/10/ixtempuse-news-novidades-sobre-o.html)


English version
A few weeks ago I announced the availability of a new script that allows a DBA to see which sessions are consuming temporary space. After release I received some feedback about it's use which triggered some changes and /or thoughts.  Specifically users faced these two issues:

1. The script didn't work in version 9.40
   After some investigation I noticed I was using a column in one of the sysmaster view which didn't exist in version 9.40. I managed to use a workaround, but after that I've found another issue when I tried to retrieve the page size of a dbspace. I was getting it from a column on the sysdbstab view, but because we only introduced the ability to have chunks of different pagesizes in V10 the column didn't exist in previous versions
2. The script didn't run when it was most needed: when the temporary dbspaces are full
   At first glance this seemed a very short sight on the way I created the script. In fact I need to create a temporary table and those will be created in the temporary dbspaces. If they're full I may have a problem. But further investigation showed the engine moves those table creation to other dbspaces. The issue seems to be the execution of the script on secondary servers when the temporary dbspaces are full.

To solve issue 1) above I did some changes in the script. It tries to adapt to the version currently being used. The solution for problem 2) is more complex. It's not feasible to do the script without the temporary tables. It could be possible but it would be very difficult. As already explained, the script should run on primary/standard servers because the engine will shift the temporary tables location to the dbspace holding a database or to rootdbs (in the case of the script it will be rootdbs as it's connecting to sysmaster). For secondary servers, this shift is not possible. The only workaround I can think of requires a "trick" and some planning in advance: A DBA can create a very small temporary dbspace (10-50MB is more than enough) without adding it to the list of dbspaces in DBSPACETEMP. And then export DBSPACETEMP=newtinydbspace to run the script. Because we're not adding it to the DBSPACETEMP $ONCONFIG parameter, it will not be used for the session's work and will be reserved for the script usage when needed. It's not a pretty solution, but it's the only I can think about currently.

Meanwhile I received some interesting feedback and I think we can see a solution for the base problem in future versions. We have to wait and see, but I really hope this script will become nearly useless in the future, which as weird as it sounds is actually a very good thing!

The new version of the script is available in the same place:
https://github.com/domusonline/InformixScripts/tree/master/scripts/ix



Versão Portuguesa
Há algumas semanas atrás anunciei a disponibilidade de um script que permite ao DBA verificar quais as sessões que estão a consumir espaço temporário. Depois disso recebi feedback sobre a sua utilização que suscitaram algumas alterações e análises. Especificamente os utilizadores depararam-se com os dois problemas seguintes::

1. O script não funcionava na versão 9.40
   Na verdade o script não era suposto funcionar, dado que não foi testado em versões sem suporte. Mas após alguma investigação verifiquei que estava a utilizar uma coluna numa das views da sysmaster. Consegui recorrer a outra forma de efetuar a query mas rapidamente bati noutra coluna que também não existia (estava a ver o tamanho da página de um dbspace numa coluna da view sysdbstab, mas como só introduzimos a possibilidade de ter dbspaces com diferentes tamanhos de página na V10, a coluna só então foi introduzida)
2. O script não corria quando era mais necessário: quando os dbspaces temporários estavam cheios
   à primeira vista parecia um erro básico na forma como construí o script. Na verdade eu necessito de criar tabelas temporárias e estas serão criadas nos temporários. Se já estão cheios é natural que tenha um problema. Mas depois de investigar, verifiquei que o motor muda a localização das tabelas temporárias para um dbspace normal (o da BD ou o rootdbs). O problema afinal trata-se da execução do script em servidores secundários quando os temporários estão cheios.

Para resolver o problema 1) acima, efetuei algumas alterações no script. Agora tenta adaptar-se à versão de motor que está a ser usada. A solução para o problema 2) é mais complexa. Não é viável fazer o script sem criar as tabelas temporárias. Não seria impossível mas seria bastante difícil. Como explicado atrás o script correrá em motores primários/standard pois o motor cria as tabelas temporárias para o dbspace onde a BD foi criada ou para o rootdbs (neste caso será sempre o rootdbs uma vez que estamos a ligar-nos à sysmaster). Mas nos servidores secundários esta adaptação não é possível. A única solução que me ocorre requer planeamento antecipado para implementar um "truque". Um DBA poderá criar  um dbspace temporário muito pequeno (10-50MB será mais que suficiente) não o adicionando à lista definida no parâmetro DBSPACETEMP no $ONCONFIG. E depois para a execução do script exportar a variável DBSPACETEMP=dbspacetemp_pequeno. Como não o adicionamos ao DBSPACETEMP do motor ele não será usado pelo trabalho normal das sessões e estará reservado para utilização do script quando necessário. Não é uma solução bonita, mas é a única que me parece possível de momento.

Entretanto recebi algum feedback interessante, e penso que poderemos ter uma solução definitiva para o problema base (saber as sessões que estão a consumir espaço temporário). Teremos de esperar para ver, mas espero que realmente este script venha a ser inútil no futuro, o que por muito estranho que pareça, é uma coisa muito boa!

A nova versão do script está disponível no mesmo endereço:
https://github.com/domusonline/InformixScripts/tree/master/scripts/ix