Informix technology

UDRs: ROWNUM in Informix / ROWNUM em Informix

2012-01-31T15:05:00.000Z

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version

ROWNUM again?!

This is more or less a FAQ. If you search the Internet for "rownum informix" you'll get a lot of links and several possible answers. I don't plan to give you a final answer, but I'll take advantage of this frequent topic to go back to something I do enjoy: User Defined functions in C language.
Most of the questions regarding ROWNUM appear in the form "does Informix support XPTO database system's ROWNUM", or "does Informix support ROW_NUMBER like database XPTO?" or even "does Informix allow the retrieval of the top N rows?" So, if you ever need something that resembles ROWNUM, the first thing you should do it to establish a clear understanding of what you need. Because the above three questions can represent three different needs, and for each need there may be a different answer. Let's see:

Does Informix support ROWNUM?
Quick answer would be no. But usually ROWNUM referes to an Oracle "magic" column that's added to the result set and that represents the position of the row in the result set. Note that this number is associated before doing ORDER BY and other clauses. So the result may not be very intuitive. Many times the purpose of using it is just to restrict the number of rows returned. Something that in ANSI (2008) SQL would be done by using the FETCH FIRST n ROWS clause. And this can be done in Informix very simply by puting a "FIRST n" before the select list:

SELECT FIRST n * FROM customer

But if you want to associate an incremental number to each row we can implement other solutions.
Does Informix allow the retrieval of the top N rows?
Yes. I just showed how to do it in the previous section. Just use the FIRST n clause. Also note that you can also use the SKIP n clause. This options are applied after all the other clauses in the SELECT. So you could use them for pagination (although it would require running the same query several times, which is not efficient).
Does Informix support row_number()?
No. And there's not much we could do. The row_number clause or function is a complex construct that can associate an incremental number to a result set, but with very flexible options that allows the numbering to restart on specific conditions etc. In order to achieve this we would need to be able to change how the query is solved. And we can't. But read on...

So, the initial purpose of this article is to explain how we can create a simple function that will generate an incremental number for each row of the result set. Sometimes this can be useful, and you'll possibly be amazed by how simple it is. There are a few challenges though... And you must be aware of how it works, or the results may surprise you.

The implementation in C

You probably heard that we can create functions in C, Java and SPL (Stored Procedure Language), but most of us only used SPL. Informix extensibility through the user defined routines (UDR) is one of it's greatest strengths, but unfortunately it's also one of the least used features. This is unfortunate not only because we're wasting a lot of potential, but also because a greater usage would probably lead to greater improvement. I'm taking this opportunity to show you how simple it can be to create a function.
In order to do it, we must follow some rules, and we should know a bit about the available API. A good place to start understanding how we can create UDRs is the User's Defined Routines and Datatypes Developer's Guide. This explains the generic concepts and the kind of UDRs we can create. Then we can check the Datablade API Programer's Guide. This has a more technical description of several aspects (like memory management, processing input and output etc.). Finally we have the Datablade API Function Reference, for specific function help and description. But of course.... reading all this without practice is more or less useless. We could use a list of examples to get us going...

So, what I propose is to create a very simple C function that can be embedded in the engine. It's use is as easy as if it was a native function. And it's creation is really simple. The language used will be C. SPL is less flexible (although it can be very handy, useful and quick). Java doesn't have easy access to the internal API, but can eventually be even more flexible for certain tasks, although a bit more complex and slower. But it really depends on your background and needs.

Before we start I should mention a few points which are in fact the hardest part of the process:

IBM bundles a few scripts with the engine that are necessary to get us started. Inside $INFORMIXDIR/incl/dbdk there are a few scripts that are simple makefiles. We may need to adapt these to the platform or compiler we're using. In my system I have:
- makeinc.gen
- makeinc.linux
- makeinc.rules
The function code needs to include some files and follow several rules.
After you create the function code, we need to compile it to object code and generate a dynamic loadable library. This is the way we make it available for the engine
After installing the library we have to create the function, telling the engine where it is available

Let's start by creating the code. As this is a crash course, I'll try to keep explanations to a minimum...:

1    /*
2    ------------------------------------------
3     include section
4    ------------------------------------------
5    */
6    #include <stdio.h>
7    #include <milib.h>
8    #include <sqlhdr.h>
9    #include <value.h>
10    
11    mi_integer ix_rownum( MI_FPARAM *fp)
12    {
13     mi_integer *my_udr_state, ret;
14    
15     /*
16     ----------------------------------------------------------
17     check to see if we've been called before on this statement
18     ----------------------------------------------------------
19     */
20     my_udr_state = (mi_integer *) mi_fp_funcstate(fp);
21     if ( my_udr_state == NULL )
22     {
23      // No... we haven't... Let's create the persistent structure
24      my_udr_state = (mi_integer *)mi_dalloc(sizeof(mi_integer),PER_STMT_EXEC);
25      if ( my_udr_state == (mi_integer *) NULL)
26      {
27       ret = mi_db_error_raise (NULL, MI_EXCEPTION, "Error in ix_rownum: Out of memory");
28       return(ret);
29      }
30      // We created it, so let's register it and initialize it to 1
31      mi_fp_setfuncstate(fp, (void *)my_udr_state);
32      (*my_udr_state)=1;
33     }
34     else
35     {
36      // If it's not the first time, then just increment the counter...
37      (*my_udr_state)++;
38     }
39     // return the counter...
40     return(*my_udr_state);
41    }

The important points are:

Lines 1-10 are just the normal and required includes
Line 11 is the function header. We define it as returning an mi_integer (on this functions we should use the mi_* datatypes). We accept one parameter which is a pointer to a function context
Line 13 where we define auxiliary variables
Line 20, we try to retrieve the previous value we kept stored in a persistent memory area. For that we use a datablade API function called mi_fp_funcstate
Lines 21-30, if the previous call returned a NULL pointer we try to allocate (mi_dalloc) memory for keeping the counter. This may be one of the most important steps. We define that the persistence criteria is PER_STMT_EXEC. This means we're keeping the context only while we're executing the same statement. We test the result and raise an error if the allocation fails
Line 31 we register the memory we have allocated as the function automatic parameter by calling mi_fp_setfuncstate()
Line 32 is the counter initialization. On the first call we define it as 1
Line 37 is the just the case for all the calls except the first. And in the generic case we just increment the counter
Line 40 is just the return of the value after initializing or incrementing it

Except for some strange but powerful functions, the code is trivial. But how do we make it available to the SQL layer? First we need to compile it and generate the dinamic library. For that I created a simple makefile:

include $(INFORMIXDIR)/incl/dbdk/makeinc.linux

MI_INCL = $(INFORMIXDIR)/incl
CFLAGS = -DMI_SERVBUILD $(CC_PIC) -I$(MI_INCL)/public $(COPTS)
LINKFLAGS = $(SHLIBLFLAG) $(SYMFLAG)

all: ix_rownum

clean:
 rm *.udr *.o

ix_rownum: ix_rownum.udr
 @echo "Library genaration done"

ix_rownum.o: ix_rownum.c
 @echo "Compiling..."
 $(CC) $(CFLAGS) -o $@ -c $?

ix_rownum.udr: ix_rownum.o
 @echo "Creating the library..."
 $(SHLIBLOD) $(LINKFLAGS) -o $@ $?

Note the inclusion of the Linux makefile I mentioned earlier. If everything goes well, after I run make I will have a dynamic loadable library called ix_rownum.udr

panther@pacman.onlinedomus.com:informix-> make
Compiling...
cc -DMI_SERVBUILD -fpic -I/usr/informix/srvr1170uc4/incl/public -g -o ix_rownum.o -c ix_rownum.c
Creating the library...
gcc -shared -Bsymbolic -o ix_rownum.udr ix_rownum.o
Library genaration done
panther@pacman.onlinedomus.com:informix->

Having done this we need to create the funcion using SQL, as an external function. The syntax can be:

CREATE FUNCTION rownum() RETURNING INTEGER
WITH (VARIANT)
EXTERNAL NAME '/home/informix/udr_tests/ix_rownum.udr(ix_rownum)'
LANGUAGE C;

We're telling the engine to create a function called rownum, which does not receive any parameter and returns an INTEGER. We specify that it's written in C and the location. Note that I'm giving it the full dynamic library path (/home/informix/udr_tests/ix_rownum.udr) and the function name inside that library (a single library can contain more than one function). And I left the explanation for "WITH(VARIANT)" for last... The external function creation allows us to specify several properties for the functions. This one, VARIANT, tells the engine that the function may return different values when called with the same parameters. This is critical since we're not passing any parameters. If we told the engine it was NOT VARIANT it would only call it once. After that it would assume the return value was 1. This is an optimization, but in our case we don't want it, since it would break the function logic. VARIANT is the default and I just include it for clarity. You can find more about the function properties here.

Working with it

Well, after the above we are able to use ROWNUM() in SQL. Let's see a few examples:

-- Example 1:
SELECT customer_num, rownum() row_num
FROM customer;
customer_num     row_num
         101           1
         102           2
         103           3
         104           4
         105           5
         106           6
         107           7
         108           8
         109           9
[...]
-- Example 2
SELECT customer_num, rownum()
FROM customer
WHERE rownum() < 5;
customer_num     row_num

         101           1
         102           2
         103           3
         104           4

-- Example 3
SELECT
        FIRST 4
        customer_num, lname
FROM
        customer
ORDER BY lname DESC;

customer_num lname

         106 Watson
         121 Wallack
         105 Vector
         117 Sipes

-- Example 4
SELECT
        customer_num , lname, rownum() row_num
FROM
        customer
WHERE rownum() < 5
ORDER BY lname DESC;

customer_num lname               row_num

         102 Sadler                    2
         101 Pauli                     1
         104 Higgins                   4
         103 Currie                    3

-- Example 5
SELECT
        t1.*, rownum() row_num
FROM (SELECT customer_num, lname FROM customer ORDER BY lname DESC) as t1 
WHERE rownum() <5;

customer_num lname               row_num

         106 Watson                    1
         121 Wallack                   2
         105 Vector                    3
         117 Sipes                     4

Let's comment the above examples. There are very important aspects to consider.

Example 1
This is the simplest example. And works as expected
Example 2
Here we are using ROWNUM() also as a filter for the WHERE clause.
Example 3
This is a auxiliary example to show a possible problem. It's just a select of customer_num and lname ordered by this in a decremental order.
Example 4
Here we're trying the same thing, but using ROWNUM() to limit the number of rows. Note that this alters the result set. Why? Because ROWNUM() is applied immediately on the full table scan. The first 4 rows are retrieved and then the ORDER BY is applied. So using ROWNUM changes the the result set, because it's applied (in the WHERE clause) before the ORDER BY.
Example 5
If we wanted to reproduce the result set from example 3, but still add a row number we could use the syntax presented here

I mentioned above that we could not reproduce the functionality of the ROW_NUMBER() construct of the SQL standard. This allows us to specify an ORDER BY clause and a PARTITION BY clause.
The ORDER BY inside the ROW_NUMBER() tells the database to order the sequence numbers by the specified filed(s). The PARTITION BY tells it to "restart" the count each time the field specified changes (similar to the effect of GROUP BY and aggregate functions). Note that this ORDER BY does not influence the order of the result set.
If you're wondering if we could implement the same functionality using functions, the answer is "sort of..." But I'll leave that for another article.

Versão Portuguesa

ROWNUM outra vez?!

Isto é uma questão que pode fazer parte dos FAQs. Se pesquisar na Internet por "rownum informix" vai obter uma série de links e algumas possíveis respostas. Não espero dar uma resposta definitiva, mas vou aproveitar este tema para voltar a um assunto que me agrada bastante: Funções definidas pelo utilizador em C.
Muitas das questões em torno do ROWNUM parecem numa das formas "o Informix suporta o ROWNUM tal como a base de dados XPTO?", ou "o Informix suporta o ROW_NUM como a base de dados XPTO?" ou ainda "o Informix suporta obter apenas as N primeiras linhas de uma query?". Assim se as suas necessidades parecem ir ao encontro do ROWNUM a primeira coisa a fazer é perceber exactamente o que se pretende. Necessidades diferentes podem ter soluções diferentes. Vamos ver:

O Informix suporta o ROWNUM?
A resposta rápida seria não. Mas habitualmente a referência a ROWNUM diz respeita a uma coluna "mágica" do Oracle, que é adicionada ao conjunto de resultados e que representa a posição de cada linha nesse mesmo conjunto. Note que este número é adicionado antes do processamento do ORDER BY e outras cláusulas e isso pode tornar o resultado pouco intuitivo. Muitas vezes é usado apenas para limitar o número de linhas obtido. Algo que em ANSI (2008) SQL seria feito com a cláusula FETCH FIRST n ROWS. E isto pode ser feito em Informix muito simplesmente com um FIRST n antes da lista de colunas:

SELECT FIRST n * FROM customer

Mas se o que pretende é associar um número incremental a cada linha podemos implementar outras soluções.
O Informix suporta obter apenas as primeiras N linhas?
Sim. Mostrei como no parágrafo anterior. Basta usar a cláusula FIRST N. Note-se que podemos também usar a cláusula SKIP n. Estas opções são aplicadas após todas as outras cláusulas do SELECT, nomeadamente o ORDER BY. Podem portanto ser usadas para paginação de resultados, embora isso leve à execução da mesma query várias vezes, o que não será muito eficiente
O Informix suporta ROW_NUMBER?
Não. E não há muito que possamos fazer. A cláusula ROW_NUMBER é complexa. Permite associar um sequência incremental de valores a um conjunto de resultados, mas com opções muito flexíveis que permitem ordenar a sequência segundo um critério e recomeçar do valor 1 sempre que certas colunas mudam. Para conseguir fazer isto teríamos de conseguir controlar a forma como o motor resolve as queries. E tal não é possível... Mas já vamos ver o que se pode fazer...

Sendo assim, o proprósito inicial deste artigo é explicar como criar uma função simples que gera un número sequencial para cada linha do conjunto de resultados. Isto pode ser útil e possivelmente ficará admirado com a simplicidade de o fazer. No entanto existem alguns desafios.... E tem de estar atento à forma como funciona, ou os resultados podem parecer inesperados.

A implementação em C

Já deve ter ouvido ou lido que podemos criar funções em C, Java e SPL (Stored Procedure Language), mas a maioria de nós apenas lidou com SPL. A capacidade de extensão do Informix através das funções definidas pelo utilizador (UDRs) é uma das suas melhores vantagens, mas infelizmente é também uma das menos usadas. Isto é mau não só porque estamos a desperdiçar muito potencial, mas também porque uma maior utilização levaria certamente a mais melhorias e desenvolvimentos. Vou aproveitar esta oportunidade para mostrar o quão simples pode ser criar uma função.
Para o fazer, temos de seguir algumas regras e devemos saber alguma coisa sobre a API disponível. Um bom sítio para começar a entender como podemos criar UDRs é o User's Defined Routines and Datatypes Developer's Guide. Isto explica os conceitos genéricos e os tipos de UDRs que podemos criar. Depois podemos consultar o Datablade API Programer's Guide. Este contém uma descrição mais técnica sobre vários aspectos (como gestão de memória, processamento de input e output etc.). Por último temos o Datablade API Function Reference, para informação e ajuda em funções específicas. Mas claro... ler isto tudo sem praticar é mais ou menos inútil. Seria bom termos uma lista de exemplos que nos permitissem arrancar....

Assim o que proponho é criar uma função muito simples em C que possa ser embebida no motor. O seu uso é tão fácil como se fosse uma função nativa do motor. E a sua criação é bastante simples. A linguagem usada será C, pois SPL é menos fléxivel (embora possa ser bastante prática, útil e rápida). O Java não tem o acesso tão fácil às funções da API interna, mas pode ainda ser mais fléxivel para algumas tarefas, embora possa ser mais complexo e lento. Mas a escolha deverá depender sempre das nossas necessidades e mesmo do nosso background com cada uma das linguagens.

Antes de começar devo referir alguns pontos que na verdade serão os mais difícieis do processo:

A IBM inclui alguns scripts no motor que são necessários para arrancarmos. Dentro de $INFORMIXDIR/incl/dbdk existem alguns makefiles simples. Poderá ser necessário adaptá-los à plataforma e/ou compilador que vamos usar.No meu sistema tenho:
- makeinc.gen
- makeinc.linux
- makeinc.rules
O código da função tem de incluir alguns ficheiros e seguir determinadas regras
Depois de criarmos o código da função temos de a compilar para código objecto e a partir deste gerar uma biblioteca dinâmica. Esta será a forma de disponibilizar a função ao motor
Depois de instalar a biblioteca temos de usar SQL para criar a função indicando ao motor onde a mesma se encontra

Vamos começar por criar o código. Como isto é um algo do tipo "mãos na massa", vou tentar manter as explicações no mínimo...:

1    /*
2    ------------------------------------------
3     secao de includes
4    ------------------------------------------
5    */
6    #include <stdio.h>
7    #include <milib.h>
8    #include <sqlhdr.h>
9    #include <value.h>
10    
11    mi_integer ix_rownum( MI_FPARAM *fp)
12    {
13     mi_integer *my_udr_state, ret;
14    
15     /*
16     ----------------------------------------------------------
17     Ver se já fomos chamados antes nesta instrução SQL
18     ----------------------------------------------------------
19     */
20     my_udr_state = (mi_integer *) mi_fp_funcstate(fp);
21     if ( my_udr_state == NULL )
22     {
23      // Não... não fomos... Vamos criar a estrutura persistente
24      my_udr_state = (mi_integer *)mi_dalloc(sizeof(mi_integer),PER_STMT_EXEC);
25      if ( my_udr_state == (mi_integer *) NULL)
26      {
27       ret = mi_db_error_raise (NULL, MI_EXCEPTION, "Erro em ix_rownum: Memória insuficiente");
28       return(ret);
29      }
30      // Já criámos, portanto vamos registar e inicializar a 1
31      mi_fp_setfuncstate(fp, (void *)my_udr_state);
32      (*my_udr_state)=1;
33     }
34     else
35     {
36      // Se não é a primeira vez vamos incrementar o contador...
37      (*my_udr_state)++;
38     }
39     // retornamos o contador...
40     return(*my_udr_state);
41    }

Os pontos importantes são:

Linhas 1-10 são os includes normais e necessários
Linha 11 é o cabeçalho da função. Definimos como retornando um mi_integer (nestas funções devemos usar os tipos de dados mi_*). Aceitamos um parâmetro que será um ponteiro para uma estrutura de contexto da função. Este parâmetro não será visível na assinatura "externa" da função (ao nível do SQL)
Linha 13 onde definimos variáveis auxiliares
Linha 20, tentamos obter o valor anterior que mantivemos na estrutura persistente de memória. Para isso usamos uma função da API dos datblades chamada mi_fp_funcstate
Linhas 21-30, se a chamada anterior devolver um ponteiro NULL, tentamos alocar (mi_dalloc) memória para manter o contador. Este será um dos passos mais importantes. Definimos que o critério de persistência é PER_STMT_EXEC. Isto significa que mantemos o contexto apenas durante a execução da mesma instrução SQL. Testamos o resultado e criamos uma excepção de a alocação falhar.
Linha 31 registamos a memória alocada anteriormente como o parâmetro automático da função através da chamada mi_fp_setfuncstate()
Linha 32 é a inicialização do contador. Na primeira chamada definimo-lo como 1
Linha 37 é apenas o caso geral, para todas as chamadas excepto a primeira. E no caso geral apenas incrementamos o contador
Linha 40 é o retorno da função, ou seja o valor do contador após inicialização ou incremento

À excepção de algumas funções estranhas, mas poderosas, o código é trivial. Mas como o disponibilizamos à camada de SQL? Antes de mais necessitamos de o compilar e gerar a biblioteca dinâmica. Para isso criamos um makefile simples:

include $(INFORMIXDIR)/incl/dbdk/makeinc.linux

MI_INCL = $(INFORMIXDIR)/incl
CFLAGS = -DMI_SERVBUILD $(CC_PIC) -I$(MI_INCL)/public $(COPTS)
LINKFLAGS = $(SHLIBLFLAG) $(SYMFLAG)

all: ix_rownum

clean:
 rm *.udr *.o

ix_rownum: ix_rownum.udr
 @echo "Geração da biblioteca completa..."

ix_rownum.o: ix_rownum.c
 @echo "Compilando..."
 $(CC) $(CFLAGS) -o $@ -c $?

ix_rownum.udr: ix_rownum.o
 @echo "Creando a biblioteca..."
 $(SHLIBLOD) $(LINKFLAGS) -o $@ $?

Note-se a inclusão do makefile Linux que mencionei anteriormente. Se tudo correr bem, após corrermos make teremos uma biblioteca dinâmica chamada ix_rownum.udr

panther@pacman.onlinedomus.com:informix-> make
Compilando...
cc -DMI_SERVBUILD -fpic -I/usr/informix/srvr1170uc4/incl/public -g -o ix_rownum.o -c ix_rownum.c
Creando a biblioteca...
gcc -shared -Bsymbolic -o ix_rownum.udr ix_rownum.o
Geração da biblioteca completa...
panther@pacman.onlinedomus.com:informix->

Após termos feito isto, necessitamos de criar a função usando SQL, como uma função externa. A sintaxe será:

CREATE FUNCTION rownum() RETURNING INTEGER
WITH (VARIANT)
EXTERNAL NAME '/home/informix/udr_tests/ix_rownum.udr(ix_rownum)'
LANGUAGE C;

Estamos a dizer ao motor para criar uma função chamada rownum, a qual não recebe nenhum parâmetro, e retorna um INTEGER. Especificamos que é escrita em C e qual a localização. Note-se que estou a dar o caminho completo da biblioteca (/home/informix/udr_tests/ix_rownum.udr) e o nome da função dentro da biblioteca (uma única biblioteca pode conter mais que uma função). Deixei a explicação para "WITH(VARIANT)" para último lugar... A criação de uma função externa permite-nos especificar várias propriedades para as funções. Esta, VARIANT, indica ao motor que a função pode retornar valores diferentes quando chamada duas ou mais vezes com os mesmos parâmetros. Isto é critico dado que não estamos a passar nenhum parâmetro. Se indicássemos ao motor que a função era NOT VARIANT apenas a chamaria uma vez. Depois disso assumiria que o valor de retorno era 1. Isto é uma optimização, mas no nosso caso não queremos que tal aconteça, dado que quebraria a lógica da função. VARIANT é o valor pré-definido, e apenas o incluí por clareza. Pode aprender mais sobre as propriedades das funções aqui:

Trabalhando com a função

Depois do exposto acima, podemos usar ROWNUM() no SQL. Vejamos alguns exemplos:

-- Exemplo 1:
SELECT customer_num, rownum() row_num
FROM customer;
customer_num     row_num
         101           1
         102           2
         103           3
         104           4
         105           5
         106           6
         107           7
         108           8
         109           9
[...]
-- Exemplo 2
SELECT customer_num, rownum()
FROM customer
WHERE rownum() < 5;
customer_num     row_num

         101           1
         102           2
         103           3
         104           4

-- Exemplo 3
SELECT
        FIRST 4
        customer_num, lname
FROM
        customer
ORDER BY lname DESC;

customer_num lname

         106 Watson
         121 Wallack
         105 Vector
         117 Sipes

-- Exemplo 4
SELECT
        customer_num , lname, rownum() row_num
FROM
        customer
WHERE rownum() < 5
ORDER BY lname DESC;

customer_num lname               row_num

         102 Sadler                    2
         101 Pauli                     1
         104 Higgins                   4
         103 Currie                    3

-- Exemplo 5
SELECT
        t1.*, rownum() row_num
FROM (SELECT customer_num, lname FROM customer ORDER BY lname DESC) as t1 
WHERE rownum() <5;

customer_num lname               row_num

         106 Watson                    1
         121 Wallack                   2
         105 Vector                    3
         117 Sipes                     4

Vamos comentar os exemplos acima. Há aspectos muito importantes a considerar:

Exemplo1
Este é o exemplo mais simples. Funciona como se esperaria
Exemplo 2
Aqui estamos a usar o ROWNUM() também como filtro da cláusula WHERE
Exemplo 3
Este é um exemplo auxiliar para ajudar a demonstrar um possível problema. É apenas um SELECT do customer_num e lname ordenado por este de forma descrescente
Exemplo 4
Aqui estamos a tentar a mesma coisa, mas usando o ROWNUM() para limitar o número de linhas. Note-se que isto altera o conjunto de resultados. Porquê? Porque o ROWNUM() é aplicado imediatamente durante o full table scan que é feito para resolver a query. As primeiras quatro linhas são obtidas, e depois o ORDER BY é aplicado. Portanto o uso do ROWNUM() altera o resultado porque é aplicado (na cláusula WHERE) antes do ORDER BY
Exemplo 5
Se quiséssemos reprodudir o resultado do exemplo 3, mas ainda assim adicionar um número de linha a cada elemento dos resultados, poderíamos usar a sintaxe apresentada aqui

Referi acima que não poderíamos reproduzir a funcionalidade da instrução ROW_NUMBER(), do standard SQL. Esta permite-nos especificar uma cláusula de ORDER BY e outra de PARTITION BY.
O ORDER BY dentro do ROW_NUMBER() indica ao motor que deve ordenar a sequência de números pelos campos indicados. O PARTITION BY diz-lhe para recomeçar a numeração cada vez que o campo indicado mudar de valor (semelhante ao efeito de um GROUP BY em agregados). Note-se que este ORDER BY não afecta a ordem dos resultados apresentados.
Se está a imaginar se não poderíamos implementar uma funcionalidade semelhante usando funções, a resposta é "mais ou menos...". Mas vou deixar isso para outro possível artigo.

DNS impact on Informix / Impacto do DNS no Informix

2012-01-09T10:30:00.000Z

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

You decided...

This article if the first "on-demand" topic I write about. I had a few options for topics I'd like to cover and I initiated a poll on a Facebook page. The impact of DNS on Informix was the most voted. So you asked for it, here it is. I will probably keep doing this from now on.
Personally I also like this topic, partially because I had several problems related to this in more than one customer. This is a relatively common issue in complex environments.
I have a public and generic disclaimer about the material I publish here, but for this case I'd like to stretch this just a bit... Beside the normal disclaimer, I'd like to state that most of the information presented here lies a bit far from my regular competencies. This is the result of a lot of digging and investigation over the time (not only from me), and there may be a few (hopefully minor) errors on the information provided. Feel free to comment, email me etc.

Very short introduction about DNS

DNS is the acronym for Domain Name System which is a protocol/service that is able to convert a hostname (e.g. onlinedomus.com) into an IP address (e.g. 89.1.2.3) and the opposite. It can also do a lot of other stuff, like telling which mail server is responsible for a specific domain etc. but this is out of the scope of the article.
Without DNS there would be no Internet as we know it. It's a critical component of the Internet infra-structure and it's performance and security is crucial for us, the users.
In a small network you can work without DNS for the basic name resolution functions, by using files. But if your network is larger, it can be very hard to use those files.
The DNS system uses an hierarchical architecture and the UDP protocol (U does not stand for unreliable but it could be...) for performance reasons. Proper configuration of a DNS system can be a complex task, and my personal experience tells me it's not very easy to find who knows how to do it properly. Furthermore, many times people don't realize the terrible impact a DNS misconfiguration or malfunction may have on the systems.
I will not explain (and I wouldn't know how to) all the DNS configuration aspects, but I'd like to reference a few points:

/etc/nsswitch.conf
This file (on Unix/Linux systems, but the name can vary) defines how the name resolution (and other services) are used. In particular it can define if the system uses files, NIS, the DNS servers or other mechanism and the order it uses. As an example, a line like:

hosts: dns files

indicates that for hostname lookups the system will first ask the DNS servers and then looks in the files
/etc/hosts
This file can map IP addresses into hostnames (and vice-versa). As an example:

89.1.2.3 www.onlinedomus.com onlinedomus.com

This tells the system that the IP address 89.1.2.3 will map to "www.onlinedomus.com" (and vice-versa). As you can imagine, a lookup for "onlinedomus.com" will also map to the same IP address.
/etc/resolv.conf
This contains the list of DNS servers that will be used for lookups and possibly a few other options (like requests timeout, names of domains that will be appended to simple hostnames, if the lookups for those hostnames fail etc.). An example:

nameserver 192.168.112.2
nameserver 9.64.162.21

How does Informix use the DNS?

From the DNS perspective, Informix is just another application. The /etc/nsswitch.conf file will tell if Informix will use the files (/etc/hosts) or the DNS servers (specified in /etc/resolv.conf). The first important thing to note is that all interaction between Informix and the DNS system goes through system calls. In particular these two functions or their equivalents or replacements:

gethostbyname()
In short, this receives an hostname and returns a structure containing the IP address
gethostbyaddr()
This receives an IP address and returns the hostname that matches it

So, if something is not working, we need to understand how/when Informix calls these two functions and how they work. Typically customers blame Informix when it's not to blame (not completely, but more on this later). Most (if not all) problems I've seen in DNS affecting Informix can affect other applications and are reproducible with very short C language programs. This does not mean we couldn't do a few things differently (better?). But again, I'll cover this later (keep in mind the disclaimer! :) )
This article is written mainly from the database server perspective. But the DNS has obvious implications for the client too... Let's start there and then I'll jump into the server.
When a client tool tries to connect to an Informix server, it starts by looking up the $INFORMIXSERVER (or equivalent given in the connection string) in the $INFORMIXSQLHOSTS file (for Java it can look up LDAP or HTTP servers for the info, but let's stick to the files for easier understanding). The file contains lines in the following format:

INFORMIXSERVER PROTOCOL HOSTNAME/IP_ADDRESS PORT_NUMBER/SERVICE_NAME OPTIONS

when the client libraries find the line matching the INFORMIXSERVER, they check the hostname (or IP address) and the port number (or service name).
Typically, if a service name is used, we look the port number in /etc/services (this can be configured in /etc/nsswitch.conf). Personally I tend to use the port number to avoid that lookup...
Then, if a hostname is used, the client must map it to an IP address. For that it calls the gethostbyname() function. This function will behave as specified in /etc/nsswitch.conf, and will try to map the name to an IP address. A failure to do that will raise error -930. This can be reproduced:

cheetah@pacman.onlinedomus.com:fnunes-> echo $INFORMIXSERVER; grep $INFORMIXSERVER $INFORMIXSQLHOSTS; dbaccess sysmaster -
blogtest
blogtest     onsoctcp     nowhere.onlinedomus.com 1500

930: Cannot connect to database server (nowhere.onlinedomus.com).
cheetah@pacman.onlinedomus.com:fnunes->

and if you need evidences of what's going on behind the scenes we can use strace (or truss):

strace -o /tmp/strace.out dbaccess sysmaster -

This is an edited extract of /tmp/strace.out generated by the command above. If you have the patience, you can see it doing the following:

Open /etc/nsswitch.conf
Open $INFORMIXSQLHOSTS (/home/informix/etc/sqlhosts)
Open /etc/services (exceptionally I used a name instead of a port number)
Open /etc/resolv.conf to find out the configured nameservers
Open a socket to 192.168.112.2 (my configured DNS server)
Ask for nowhere.onlinedomus.com
Open /etc/hosts (in /etc/nsswtich.conf I configured to search the files if the DNS lookup fails)
Read the error message from the Informix message files
Write the error message to stderr
Exit with error code -1

cheetah@pacman.onlinedomus.com:fnunes-> cat /tmp/strace.out
[...]
open("/etc/nsswitch.conf", O_RDONLY)    = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1803, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7862000
read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1803
read(3, "", 4096)                       = 0
close(3)                                = 0
[...]
open("/home/informix/etc/sqlhosts", O_RDONLY|O_LARGEFILE) = 4
_llseek(4, 0, [0], SEEK_SET)            = 0
read(4, "blogtest     onsoctcp     nowher"..., 4096) = 1389
[...]
open("/etc/services", O_RDONLY|O_CLOEXEC) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=644327, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7862000
read(4, "# /etc/services:\n# $Id: services"..., 4096) = 4096
close(4)                                = 0
[...]
open("/etc/resolv.conf", O_RDONLY)      = 4
[...]
read(4, "", 4096)                       = 0
close(4)                                = 0
[...]
open("/lib/libresolv.so.2", O_RDONLY)   = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0Pf\256\0004\0\0\0"..., 512) = 512
[...]
close(4)                                = 0
[...]
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
gettimeofday({1325590403, 502576}, NULL) = 0
poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
send(4, "tl\1\0\0\1\0\0\0\0\0\0\7nowhere\vonlinedomus"..., 41, MSG_NOSIGNAL) = 41
poll([{fd=4, events=POLLIN}], 1, 5000)  = 1 ([{fd=4, revents=POLLIN}])
ioctl(4, FIONREAD, [101])               = 0
recvfrom(4, "tl\201\203\0\1\0\0\0\1\0\0\7nowhere\vonlinedomus"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, [16]) = 101
close(4)                                = 0
[...]
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
[...]
read(4, "127.0.0.1\tpacman1.onlinedomus.ne"..., 4096) = 439
[...]
close(4)                                = 0
[...]
read(3, "Cannot connect to database serve"..., 40) = 40
write(2, "\n", 1)                       = 1
write(2, "  930: Cannot connect to databas"..., 68) = 68
exit_group(-1)                          = ?
cheetah@pacman.onlinedomus.com:fnunes->

Now, we should move to the Informix server side. This requires a bit more work and preliminary explanations. To start, we must understand what the engine needs in order to establish the connection. One of those things is to do a reverse name lookup (IP address to hostname). This is not essential, but it's always tried. Informix may need the hostname for trust relation validation and to provide information to the DBA.

As you know, the Informix database engine comprises several operating system processes. From the OS perspective they all look the same (oninit), but every one has a specific role and runs certain engine threads. We can see the threads with:

panther@pacman.onlinedomus.com:fnunes-> onstat -g ath

IBM Informix Dynamic Server Version 11.70.UC4 -- On-Line -- Up 00:17:01 -- 411500 Kbytes

Threads:
 tid     tcb      rstcb    prty status                vp-class       name
 2       5583fa38 0        1    IO Idle                 3lio*        lio vp 0
 3       558551f8 0        1    IO Idle                 4pio*        pio vp 0
 4       5586b1f8 0        1    IO Idle                 5aio*        aio vp 0
 5       558811f8 8f59dc0  1    IO Idle                 6msc*        msc vp 0
 6       558af1f8 0        1    IO Idle                 7fifo*       fifo vp 0
 7       558c9590 0        1    IO Idle                 9aio*        aio vp 1
 8       558df3b8 54267018 3    sleeping secs: 1        8cpu         main_loop()
 9       559276f8 0        1    running                10soc*        soctcppoll
 10      5593ed18 0        2    sleeping forever        1cpu*        soctcplst
 11      55927d20 542675fc 1    sleeping secs: 1        8cpu         flush_sub(0)
 12      55988018 54267be0 1    sleeping secs: 1        8cpu         flush_sub(1)
 13      559881f0 542681c4 1    sleeping secs: 1        8cpu         flush_sub(2)
 14      559883c8 542687a8 1    sleeping secs: 1        8cpu         flush_sub(3)
 15      559885a0 54268d8c 1    sleeping secs: 1        8cpu         flush_sub(4)
 16      55988778 54269370 1    sleeping secs: 1        8cpu         flush_sub(5)
 17      55988bf0 54269954 1    sleeping secs: 1        8cpu         flush_sub(6)
 18      559fb468 54269f38 1    sleeping secs: 1        8cpu         flush_sub(7)
 19      559fb640 0        3    IO Idle                 8cpu*        kaio
 20      55ab6018 5426a51c 2    sleeping secs: 1        8cpu         aslogflush
 21      55ab6960 5426ab00 1    sleeping secs: 92       1cpu         btscanner_0
 22      55b6a408 5426b0e4 3    cond wait  ReadAhead    1cpu         readahead_0
 39      55bcd5c8 0        3    IO Idle                 1cpu*        kaio
 40      55bcd7a0 5426bcac 3    sleeping secs: 1        1cpu*        onmode_mon
 41      55d3e148 5426c874 3    sleeping secs: 1        8cpu         periodic
 49      55e80a78 5426da20 1    sleeping secs: 177      1cpu         dbScheduler
 51      55f340f8 5426d43c 1    sleeping forever        1cpu         dbWorker1
 52      55f34d80 5426ce58 1    sleeping forever        8cpu         dbWorker2
 59      562ee228 5426e5e8 1    cond wait  bp_cond      1cpu         bf_priosweep()

And the OS processes with:

panther@pacman.onlinedomus.com:fnunes-> onstat -g glo

IBM Informix Dynamic Server Version 11.70.UC4 -- On-Line -- Up 00:18:48 -- 411500 Kbytes

MT global info:
sessions threads  vps      lngspins
0        29       10       3       

          sched calls     thread switches yield 0   yield n   yield forever
total:    9589515         8992470         597961    14485     4457836  
per sec:  0               0               0         0         0        

Virtual processor summary:
 class       vps       usercpu   syscpu    total   
 cpu         2         11.51     94.06     105.57  
 aio         2         3.57      75.44     79.01   
 lio         1         0.01      0.01      0.02    
 pio         1         0.00      0.01      0.01    
 adm         1         0.01      0.15      0.16    
 soc         1         0.04      0.15      0.19    
 msc         1         0.00      0.01      0.01    
 fifo        1         0.00      0.01      0.01    
 total       10        15.14     169.84    184.98  

Individual virtual processors:
 vp    pid       class       usercpu   syscpu    total     Thread    Eff  
 1     29395     cpu         5.63      46.80     52.43     66.41     78%
 2     29398     adm         0.01      0.15      0.16      0.00       0%
 3     29399     lio         0.01      0.01      0.02      0.02     100%
 4     29400     pio         0.00      0.01      0.01      0.01     100%
 5     29401     aio         3.29      74.30     77.59     77.59    100%
 6     29402     msc         0.00      0.01      0.01      0.03      31%
 7     29403     fifo        0.00      0.01      0.01      0.01     100%
 8     29404     cpu         5.88      47.26     53.14     64.45     82%
 9     29405     aio         0.28      1.14      1.42      1.42     100%
 10    29406     soc         0.04      0.15      0.19      NA         NA
                 tot         15.14     169.84    184.98

The threads that are listening on the engine TCP ports are the poll threads (soctcppoll) running on SOC class (this depends on the NETTYPE parameter). When a new request is received by them they call the listener threads (soctcplst) running on the cpu class to initiate the authentication process. Parts of this task are run by the MSC virtual processor. As we can see in the last output this has the PID 29402. So, in order to see what happens I'll trace that OS process. For reasons that I'll explain later, I will turn off the NS_CACHE feature (Informix 11.7) and I will restart the engine. So, for the first connection attempt we get (some parts cut off):

1      0.000000 semop(753664, {{5, -1, 0}}, 1) = 0
2      7.009868 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
3      0.000107 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
4      0.000242 close(3)                  = 0
5      0.000060 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
6      0.000063 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
7      0.000095 close(3)                  = 0
8      [...]
9      0.000000 open("/etc/resolv.conf", O_RDONLY) = 3
10     0.000000 fstat64(3, {st_mode=S_IFREG|0644, st_size=55, ...}) = 0
11     0.000000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xab4000
12     0.000000 read(3, "# Generated by NetworkManager\nna"..., 4096) = 55
13     0.000926 read(3, "", 4096)         = 0
14     0.000050 close(3)                  = 0
15     [...]
16     0.000057 futex(0x29ab44, FUTEX_WAKE_PRIVATE, 2147483647) = 0
17     0.000256 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
18     0.000089 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
19     0.000107 gettimeofday({1325605320, 167025}, NULL) = 0
20     0.000072 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
21     0.000083 send(3, "\363\337\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
22     0.000322 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
23     2.061369 ioctl(3, FIONREAD, [121]) = 0
24     0.000111 recvfrom(3, "\363\337\201\203\0\1\0\0\0\1\0\0\0011\003112\003168\003192\7in-ad"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, [16]) = 121
25     0.000155 close(3)                  = 0
26     0.000090 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
27     0.000377 fstat64(3, {st_mode=S_IFREG|0644, st_size=439, ...}) = 0
28     0.000089 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf22000
29     0.000057 read(3, "127.0.0.1\tpacman1.onlinedomus.ne"..., 4096) = 439
30     0.000130 close(3)                  = 0
31     [...]
32     0.000072 semop(753664, {{7, 1, 0}}, 1) = 0
33     0.000069 semop(753664, {{7, 1, 0}}, 1) = 0
34     0.007558 semop(753664, {{5, -1, 0}}, 1

Please note that for clarity I added line numbers and time differences between each call (this will be important later). Let's explain this.

On line 1) we have a semop() which is the way MSC VP stays idle. That was before the connection attempt.
7 seconds later it tries to "talk" with nscd daemon (lines 2-8). This is kind of a Linux specific mechanism that I'm not running. Then accesses the /etc/nsswitch.conf. Just keep in memory that it did this on the first attempt
Then it accesses /etc/resolv.conf (lines 9-15) and finds the nameserver address
On lines 16-25 it talks to the DNS server (192.168.112.2) and asks for the reverse name of the connecting IP address
Since the answer is inconclusive, it goes to /etc/hosts (lines 26-31)
I have cut the remaining part which is related to the authentication (opening the /etc/passwd, /etc/group, /etc/shadow etc.).
Finally it returns to the normal idle state

A few important points about this:

It all happened pretty quick (values are in seconds)
We don't see the gethostbyaddr() call. This is not a "system call" for strace. So we see the lower level calls, but not the gethostbyaddr() function. We can catch it by attaching a debugger to the same process. This is important because usually it's hard to discuss this issues with the network and OS administrators because they tend to assume all this is done by Informix. It isn't! Informix just calls gethostbyaddr() (or equivalent fiunctions)

Now, let's see the same for the second attempt. We would expect it to be the same, but it isn't. I have cut exactly the same parts:

1      0.000000 semop(753664, {{5, -1, 0}}, 1) = 0
2      6.452154 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
3      0.000099 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
4      0.008816 gettimeofday({1325605445, 534040}, NULL) = 0
5      0.000089 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
6      0.000100 send(3, "\233\t\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
7      0.000417 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
8      2.089726 ioctl(3, FIONREAD, [121]) = 0
9      0.000118 recvfrom(3, "\233\t\201\203\0\1\0\0\0\1\0\0\0011\003112\003168\003192\7in-ad"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, [16]) = 121
10     0.000132 close(3)                  = 0
11     0.000069 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
12     0.000102 fstat64(3, {st_mode=S_IFREG|0644, st_size=439, ...}) = 0
13     0.000092 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xe1f000
14     0.000064 read(3, "127.0.0.1\tpacman1.onlinedomus.ne"..., 4096) = 439
15     0.000099 close(3)                  = 0
16     [...]
17     0.000068 semop(753664, {{0, 1, 0}}, 1) = 0
18     0.000096 semop(753664, {{0, 1, 0}}, 1) = 0
19     0.000076 semop(753664, {{5, -1, 0}}, 1

So, again the analysis:

The first part accessing the nscd daemon, the /etc/nsswitch.conf and the /etc/resolv.conf is completely gone.
As you can see it starts by connecting to the DNS.
Then it reads the files (/etc/hosts)
Then I cut the authentication part as before
Finally it returns to the idle state

The important point to note here is that the first attempt is different from the others. And again, Informix just calls gethostbyaddr()... just the same call each time. Well... to be correct the function we call may depend on the platform. As I mentioned earlier, only by using a debugger we can find the gethostbyaddr() call. I've done it and here is the result:

(gdb) break connect
Breakpoint 1 at 0x95f640
(gdb) continue
Continuing.

Breakpoint 1, 0x0095f640 in connect () from /lib/libpthread.so.0
(gdb) where
#0  0x0095f640 in connect () from /lib/libpthread.so.0
#1  0x00aec9ab in reopen () from /lib/libresolv.so.2
#2  0x00aee542 in __libc_res_nsend () from /lib/libresolv.so.2
#3  0x00aeb24e in __libc_res_nquery () from /lib/libresolv.so.2
#4  0x002b6dc7 in _nss_dns_gethostbyaddr2_r () from /lib/libnss_dns.so.2
#5  0x002b6f1a in _nss_dns_gethostbyaddr_r () from /lib/libnss_dns.so.2
#6  0x0020890b in gethostbyaddr_r@@GLIBC_2.1.2 () from /lib/libc.so.6
#7  0x00211f77 in getnameinfo () from /lib/libc.so.6
#8  0x08c0e664 in ifx_getipnodebyaddr ()
#9  0x08c0f79c in ifx_gethostbyaddr ()
#10 0x08c0f8a2 in __osgethostbyaddr ()
#11 0x08b0c055 in aio_workon ()
#12 0x08b0c9c3 in aiothread ()
#13 0x08b0dbcb in iothread ()
#14 0x08b00762 in startup ()
#15 0x558749e8 in ?? ()
#16 0x00000000 in ?? ()
(gdb)

As you can see I've setup a breakpoint for connect(). Then I "continue" the execution and I try the connection. gdb stops the program at the breakpoint and I get the stack trace (read bottom up).
So, it shows we call getnameinfo() which in turn calls gethostbyaddr_r() etc. All this belongs to the system libraries, not to Informix code.

There are two additional considerations we need to be aware. First, the Informix MSC VP processes it's requests in a serial manner. For each connection it asks what it needs from the DNS servers and/or files and makes the authentication. By default we only have one MSC VP... so if one request gets stuck.... yes... the following connections will suffer delays. This delays can be a fraction of second, or a few seconds, but on some systems I've seen tens (heard about hundreds) of connections per second, so even a few seconds will have large impact.
The second consideration relates to the differences between the first call and the subsequent ones. As we've seen above, on the first call the process checks the configuration (the /etc/nsswitch.conf and /etc/resolv.conf files). After that first check it does not do that anymore. And this causes a problem. Again this is the behavior of the system functions (but not necessarily the end of the story....)

So, hopefully I was able to explain how Informix interacts with the DNS system. The important technical deep dive should be over. We'll proceed to the implications. It's important you understand all the above before proceeding to the next paragraphs.

What problems can we face?

Above I've tried to show you how things work when everything is ok. But what happens when something is wrong? Let's see what can go wrong first and then the implications. I'll also try to explain who to blame (and again the disclaimer...). The purpose of course is not to finger point, but knowing where the problem lies is the first step to solve it.

Network problems prevent the connection to the DNS servers
If this happens, the requests sent by the MSC VP will have to timeout (typically a few seconds) before the OS call returns. This delay will cause all the other connection requests to stay on hold (assuming we just have one MSC VP). If the network problems persist, it really doesn't matter how many MSC VPs we have, since they'll all get stuck and all our connection attempts will suffer delays
The DNS server dies, is stopped, or is extremely slow
The effect of this is very similar to the previous. Anything that causes delays in the DNS requests will potentially cause delays in the engine connections. Note that this can be a generic issue that affects all the requests, or it can affect only some requests. Due to the hierarchical and distributed nature of the DNS system, it may be able to answer most requests, but get slow or event try to "talk" to an unavailable server for some specific names or IP addresses. Needless to say this makes the debug of these problems very difficult to do
Something goes wrong with the DSN system. The reverse lookups fail and this affects the trusted connections.
You start to see -956 errors in the online.log and -951 is sent to the client side
You need to change your DNS servers
Then you''ll need to restart Informix. This is a nasty problem caused by Informix (we could do better). As I mentioned above, the OS function calls keep the configurations in memory for efficiency reasons (it would be very "expensive" to re-read that for each call). So, the problem in how it works is that if you want to change the policy (/etc/nsswitch.conf) or the DNS servers (/etc/resolv.conf), the Informix processes will not pick up the change. I can assure you that Informix is not the only daemon that suffers with this. The first time I had a similar problem with this, I noticed that for example sendmail was also suffering... (trying to talk with the older servers)

From the above problems it's easy to understand that the three first are not Informix's fault. When a customer decides (presumably because it needs) to use a DNS infra-structure people have to understand that it automatically becomes a critical component of the system. Any problems in it will cause problems in the layers above, specifically in the Informix system.
And that leaves us with the forth problem. I wrote before and it's true that this is how the functions work (and I'll show this in action), so why do I write that this is Informix's fault? Well, because there is a way to handle this. There is another system call named res_init() that does precisely what we need. From the Linux manual, I quote:

The res_init() function reads the configuration files (see resolv.conf(5)) to get the default domain name, search order and name server address(es).
If no server is given, the local host is tried. If no domain is given, that associated with the local host is used. It can be overridden with the environment variable LOCALDOMAIN. res_init() is normally executed by the first call to one of the other functions.

So, my point is that Informix should provide a way by which the DBA would request all the MSC VPs to call this function. This would refresh the information that is cached by the first call.
In fact IBM has a pending feature request about this. I really hope this could be implemented in a future release. This is something that we may live without for years, but if you need it, it really would make a difference

Knowing if you have the problem

How do we know that we have a problem in DNS and that Informix is being impacted? Typically you'll get some sort of complain from the Informix clients. Usually something like "the database is terribly slow", or "it takes a long time to connect", or eventually you'll have connections refused with server side error -956 (not trusted). In extreme situations you can have weird errors in the online.log (-25xxx ). In all these situations you'll notice that the already existing sessions are working smoothly.
But in order to be sure you may follow two paths:

The most simple is to run a "netstat -a" command on the database server. This shows all the TCP/UDP connections to and from the machine. By default it will go through all the socket connections and will try to reverse lookup the respective IP addresses. If you're having problems you'll see that the netstat output will be very slow or at least with some "bumps". But for this simple tests to provide meaningful conclusions, you must be sure that the system is still configured to use the same configuration (/etc/nsswitch.conf and /etc/resolv.conf) that was in place when the Informix engine was started. Otherwise you'll not be comparing apples to apples
The most complex is to run a truss or strace command against the MSC VP with timings. This can show slow response from the calls to the DNS hosts. Be aware that running truss/strace requires root privileges and that even if everything is running fine, it will cause delays on systems with a large number of connects per second

I wrote earlier that I could demonstrate the facts presented here without using Informix. For that I created a simple program (line numbers included):

1  #include <sys/time.h>
2  #include <netdb.h>
3  #include <resolv.h>
4  #include <stdlib.h>
5  #include <string.h>
6  
7  int main(int argc, char **argv)
8  {
9    struct hostent *hp;
10    in_addr_t data;
11    char buff[100];
12    struct timeval ts_initial, ts_final;
13  
14    if (argc == 2) {
15      strcpy(buff,argv[1]);
16    }
17    else {
18      printf("Introduce an IP address: ");
19      if (fscanf(stdin,"%s", buff) == EOF)
20        exit(0);
21    }
22  
23    while (1 == 1) {
24      data = inet_addr(buff);
25      gettimeofday(&ts_initial, NULL);
26      hp = gethostbyaddr(&data, 4, AF_INET);
27      gettimeofday(&ts_final, NULL);
28  
29      if (hp == NULL) {
30        printf("Unknown host (%s). Took %f seconds\n", buff, (double)((ts_final.tv_sec * 1000000 + ts_final.tv_usec) - (ts_initial.tv_sec * 1000000 + ts_initial.tv_usec))/1000000);
31      }
32      else {
33        printf("Name (%s): %s Took %f seconds\n", buff, hp->h_name, (double)((ts_final.tv_sec * 1000000 + ts_final.tv_usec) - (ts_initial.tv_sec * 1000000 + ts_initial.tv_usec))/1000000);
34      }
35      printf("Next: ");
36      if (fscanf(stdin,"%s", buff) == EOF)
37        exit(0);
38      if ( strncmp("refresh", buff, 7) == 0 )
39      {
40         res_init();
41         printf("Called res_init()\n");
42         printf("Next: ");
43         if (fscanf(stdin,"%s", buff) == EOF)
44           exit(0);
45      }
46    }
47  }

This is basically a loop that reads an IP address (which are not validated, so it's easily breakable), and runs gethostbyaddr() on it. If the "ip" provided is "refresh" then it calls res_init(). It reports the information returned by the resolver subsystem and the time it took. You can use it interactively or redirect a file with one IP address per line.

I'll run it interactively with tracing in order to show the effect of calling res_init(). I have "hosts: dns,files" in /etc/nsswitch.conf and 192.168.112.2 on /etc/resolv.conf. This file also contains options do define the timeout to 2 seconds. So I call this with:

cheetah@pacman1.onlinedomus.net:fnunes-> strace -r -o test_resolv.trace ./test_resolv
Introduce an IP address: 1.1.1.1
Unknown host (1.1.1.1). Took 2.010235 seconds
Next: 1.1.1.2
Unknown host (1.1.1.2). Took 2.003324 seconds
Next: refresh
Called res_init()
Next: 1.1.1.3
Unknown host (1.1.1.3). Took 2.004002 seconds
Next: ^C

Before I introduce "refresh" I change the DNS nameserver in /etc/resolv.conf from 192.168.112.2 to 192.168.112.5.
The trace is this (line numbers and timmings added):

1        [...]
2        0.000000 write(1, "Introduce an IP address: ", 25) = 25
3        0.000000 read(0, "1.1.1.1\n", 1024) = 8
4        3.055699 gettimeofday({1325865284, 104186}, NULL) = 0
5        [...]
6        0.000160 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
7        0.000099 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
8        0.000128 close(3)                  = 0
9        0.000053 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
10       0.000123 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
11       0.000122 close(3)                  = 0
12       0.000095 open("/etc/nsswitch.conf", O_RDONLY) = 3
13       0.000108 fstat64(3, {st_mode=S_IFREG|0644, st_size=1803, ...}) = 0
14       0.000101 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
15       0.000057 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1803
16       0.000001 read(3, "", 4096)         = 0
17       0.000000 close(3)                  = 0
18       [...]
19       0.000055 open("/etc/resolv.conf", O_RDONLY) = 3
20       0.000072 fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
21       0.000095 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
22       0.000050 read(3, "# Generated by NetworkManager\nna"..., 4096) = 118
23       0.000086 read(3, "", 4096)         = 0
24       0.000046 close(3)                  = 0
25       [...]
26       0.000173 open("/etc/host.conf", O_RDONLY) = 3
27       0.000068 fstat64(3, {st_mode=S_IFREG|0644, st_size=26, ...}) = 0
28       0.000081 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
29       0.000179 read(3, "multi on\norder hosts,bind\n", 4096) = 26
30       0.000083 read(3, "", 4096)         = 0
31       0.000048 close(3)                  = 0
32       0.000049 munmap(0xb7843000, 4096)  = 0
33       0.000160 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
34       0.000075 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
35       0.000640 gettimeofday({1325865284, 108850}, NULL) = 0
36       0.000062 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
37       0.000094 send(3, "r\363\1\0\0\1\0\0\0\0\0\0\0011\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
38       0.000889 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
39       2.003373 close(3)                  = 0
40       0.000109 open("/etc/ld.so.cache", O_RDONLY) = 3
41       0.000078 fstat64(3, {st_mode=S_IFREG|0644, st_size=72238, ...}) = 0
42       0.000093 mmap2(NULL, 72238, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7821000
43       0.000054 close(3)                  = 0
44       [...]
45       0.000105 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
46       0.000097 fcntl64(3, F_GETFD)       = 0x1 (flags FD_CLOEXEC)
47       0.000065 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
48       0.000053 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
49       0.000035 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
50       0.000137 read(3, "", 4096)         = 0
51       0.000130 close(3)                  = 0
52       [...]
53       0.000101 write(1, "Unknown host (1.1.1.1). Took 2.0"..., 46) = 46
54       0.000071 write(1, "Next: ", 6)     = 6
55       0.000267 read(0, "1.1.1.2\n", 1024) = 8
56       0.000071 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
57       0.000077 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
58       0.000049 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
59       0.000063 send(3, ":\243\1\0\0\1\0\0\0\0\0\0\0012\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
60       0.000152 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
61       2.002550 close(3)                  = 0
62       0.000088 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
63       0.000077 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
64       0.000092 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
65       0.000057 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
66       0.000110 read(3, "", 4096)         = 0
67       0.000049 close(3)                  = 0
68       [...]
69       0.000060 write(1, "Unknown host (1.1.1.2). Took 2.0"..., 46) = 46
70       0.000076 write(1, "Next: ", 6)     = 6
71       0.000253 read(0, "refresh\n", 1024) = 8
72      17.639011 open("/etc/resolv.conf", O_RDONLY) = 3
73       0.000088 fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
74       0.000087 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
75       0.000052 read(3, "# Generated by NetworkManager\n#n"..., 4096) = 118
76       0.000108 read(3, "", 4096)         = 0
77       0.000047 close(3)                  = 0
78       0.000048 munmap(0xb7843000, 4096)  = 0
79       0.000065 write(1, "Called res_init()\n", 18) = 18
80       0.000060 write(1, "Next: ", 6)     = 6
81       0.000051 read(0, "1.1.1.3\n", 1024) = 8
82       3.595382 gettimeofday({1325865312, 174933}, NULL) = 0
83       0.000075 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
84       0.000078 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.5")}, 16) = 0
85       0.000266 gettimeofday({1325865312, 175350}, NULL) = 0
86       0.000052 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
87       0.000069 send(3, "\321\234\1\0\0\1\0\0\0\0\0\0\0013\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
88       0.000085 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
89       2.002271 close(3)                  = 0
90       0.000081 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
91       0.000076 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
92       0.000087 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
93       0.000054 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
94       0.000091 read(3, "", 4096)         = 0
95       0.000047 close(3)                  = 0
96       0.000048 munmap(0xb7843000, 4096)  = 0
97       0.000062 gettimeofday({1325865314, 178373}, NULL) = 0
98       0.000058 write(1, "Unknown host (1.1.1.3). Took 2.0"..., 46) = 46
99       0.000072 write(1, "Next: ", 6)     = 6
100      0.000053 read(0, 0xb7844000, 1024) = ? ERESTARTSYS (To be restarted)
101      0.918564 --- SIGINT (Interrupt) @ 0 (0) ---
102      0.000931 +++ killed by SIGINT +++

And the explanation:

Lines 1-5 the program starts and asks for the IP address. 1.1.1.1 is provided
Lines 6-18 it tries to contact the nscd (Linux caching daemon) and then opens and reads /etc/nsswitch.conf
Lines 19-31 opens the other two configuration files (/etc/resolv.conf and /etc/host.conf)
Lines 33-44 contacts the DNS server on 192.168.112.2 (timeout = 2s)
Lines 45-52 reads /etc/hosts and prints the result (Unknown host)
Lines 53-68 is just the same, but doesn't read the config files since it's not the first time
Lines 69-79 I insert "refresh" and it calls res_init() and re-reads /etc/resolv.conf. Meanwhile, just before that I changed the /etc/resolv.conf and put 192.168.112.5
Lines 80-99 I insert another IP address (1.1.1.3) and it goes to the new DNS server (192.168.112.5). Failing to get a proper answer re-reads the /etc/hosts.
Lines 100-102 it was asking for another IP address and I pressed Control+C

Hacking it just for fun!

Please don't try this at home!.. Really, the following is something risky, not supported, and for learning purposes only. I argued above that calling res_init() would allow you to change the DNS servers without restarting Informix. Let's prove it!
Again I traced a connection, looking at MSC VP. I get this:

socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
gettimeofday({1326038028, 174740}, NULL) = 0
poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])
send(3, "+\316\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
poll([{fd=3, events=POLLIN}], 1, 2000)  = 0 (Timeout)
close(3)                                = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x12f000
read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
close3)

It is connecting to 192.168.112.2, which is what I have on /etc/resolv.conf. If I change that on the file to 192.168.112.5 and try to connect again, the same thing happens (it's not aware of the change). But now, without further changes in the file I run a debugger against the MSC VP process:

[root@pacman tmp]# gdb -p 4649
GNU gdb (GDB) Fedora (7.1-18.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http: bugs="" gdb="" software="" www.gnu.org="">.
Attaching to process 4649
Reading symbols from /usr/informix/srvr1170uc4/bin/oninit...(no debugging symbols found)...done.
[...]
(gdb) call __res_init()
$1 = 0
(gdb) detach
Detaching from program: /usr/informix/srvr1170uc4/bin/oninit, process 4649
(gdb) quit
[root@pacman tmp]#

And I "call" the __res_init() function which I checked to be defined in the libc.so code. Let's trace another connection now:

socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.5")}, 16) = 0
gettimeofday({1326038409, 784712}, NULL) = 0
poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])
send(3, "\364K\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
poll([{fd=3, events=POLLIN}], 1, 2000)  = 0 (Timeout)
close(3)                                = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x12f000
read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
close(3)

Ups! Hacked!... Of course this is not supported. Don't try this on real servers. It just serves the purpose of proving a point.

Conclusions

What I tried to demonstrate in this article is how Informix interacts with the DNS system, if you configure DNS in your environment. I hope that I made clear that once DNS is in place it takes a very important role in the connection process. So much that a bad function in DNS will have major impact in the database system. There are a few points that are Informix responsibility that can contribute to the impact. In particular:

The fact that the reverse DNS requests are made by the MSC VP(s) can generate delays in requests that would work ok, just because a previous one has a problem. Having more than one MSC VP can greatly alleviate this, but may not solve it
The fact that Informix doesn't establish timeouts to the gethostbyname() calls - or equivalent - can also lead to unnecessary delays. But note that the functions signatures don't have any way to ask for this, so an alarm would have to be setup, so that the process would receive a signal and then check if it was still waiting on the function. This would cause additional overhead, that would not make sense specially because the timeouts are possible to configure in the generic DNS configuration
The fact that the functions called, cache the configuration details, allied to the fact that Informix has no way to clear the cache, means that a change in the DNS addresses will require a stop in the database system. There is a feature request to allow this. I'd love to see this implemented.

On the other hand, Informix 11.7 introduced a great feature to ease all this. With the NS_CACHE parameter we can configure the cache times for several systems (DNS, users/passwords, services...). This can reduce to a minimum the number of requests. Of course, as with any other caching mechanism the risk is to have stalled entries. But we can clear any of the caches by using "onmode -wm NS_CACHE=..." and using a timeout of zero. This would be a great place to call res_init() by the way...

To roundup the article I'd like to mention a few best practices:

Use Informix 11.7 if you can, so that you can take advantage of the caching. Your DNS servers and DNS admins will appreciate it if you have high connection rates
Consider including "files" in the /etc/nsswitch.conf configuration. Some people consider this a bad idea, because it keeps the /etc/hosts file very busy. But if you keep it short and use the cache of Informix 11.7 it shouldn't be too bad. And it can save you if your DNS blows away (you could then add entries to the /etc/hosts file even temporarily). Note that at least in my test system (Linux) not even res_init makes the process re-read /etc/nsswitch.conf
Make sure your DNS admins and DBA get along... They must work together and should be aware that their systems are tightly connected
Use Informix 11.7 if you can, so that you can use REMOTE_SERVER_CFG. Many companies don't allow the DBA to manage the /etc/hosts.equiv files (system files). If you have a problem in DNS, and your reverse DNS queries start to fail, your trusted connections will fail if they use the names and not the IP addresses. So, in critical situations it may be useful that the DBAs can act immediately and add the IP addresses in the trusted lists. With REMOTE_SERVER_CFG they'll be able to do it.
Use very small timeouts configured in /etc/resolvs.conf (1-2s) to minimize the waisted wait time (a successful query to a DNS is pretty quick

Versão Portuguesa:

Você decidiu...

Este artigo é o primeiro publicado após opinião dos leitores. Tinha algumas opções para assuntos a abordar e iniciei um inquérito numa página do Facebook. O impacto do DNS no Informix foi o mais votado. E a vontade expressa foi cumprida. Provavelmente continuarei a fazer isto de ora em diante.
Pessoalmente o assunto agrada-me porque já enfrentei problemas relacionados com o DNS em mais que um cliente É um assunto algo frequente em ambientes complexos.
O blog tem um termo de desresponsabilização público e genérico, mas neste caso gostaria de o enfatizar um pouco... Para além do normal, gostaria de deixar claro que a informação que se segue foge um pouco às minhas competências "regulares". É o resultado de bastante investigação ao longo fo tempo (e não só minha) e pode conter alguns (espero que poucos e pouco importantes) erros. Não se acanhe de comentar, corrigir, sugerir alterações por aqui ou por email etc.

Pequena introdução ao DNS

DNS é um acrónimo de Domain Name System, que é o protocolo/serviço capaz de converter um nome (ex: onlinedomus.com) num endereço TCP/IP (ex: 89.1.2.3) e vice-versa. Pode ainda fazer uma série de outras coisas, como indicar qual o servidor de email responsável por um determinado domínio etc., mas isso já sai do âmbito deste artigo.
Sem DNS não haveria Internet como a conhecemos. É um componente crítico da infra-estrutura da Internet, e a sua eficiência e segurança é crucial para nós, os utilizadores
Numa pequena rede podemos passar sem DNS para as funções básicas de resolução de nomes, usando ficheiros. Mas em redes mais complexas e maiores, pode ser muito complicado e penoso gerir isso usando apenas ficheiros.
O sistema de DNS tem uma arquitectura hierárquica e usa o protocolo UDP (U não significa unreliable mas podia...) por questões de performance. Configurar devidamente um sistema DNS pode ser uma tarefa complexa e a minha experiência diz-me que não é muito fácil encontrar quem o saiba fazer correctamente. Ainda mais, na maioria dos casos as pessoas não têm a correcta noção do terrível impacto que uma má configuração no DNS pode ter nos sistemas.
Não vou explicar (não o saberia fazer) todos os aspectos de configuração de DNS, mas quero referir alguns pontos:

/etc/nsswitch.conf
Este ficheiro (em sistemas Unix/Linux, mas o nome pode mudar) define como a resolução de nomes (e outros serviços) é efectuada. Mais especificamente define se o sistema usa ficheiros, NIS, servidores de DNS ou outros mecanismos e a ordem porque o faz. Como exemplo, uma linha como:

hosts: dns files

indica que as pesquisas de nomes e IPs são feitas primeiro usando os servidores de DNS e depois ficheiros
/etc/hosts
Este ficheiro mapeia os endereços IPs em nomes (e vice-versa). Por exemplo:

89.1.2.3 www.onlinedomus.com onlinedomus.com

Isto indica ao sistema que o endereço IP 89.1.2.3 mapeia para "www.onlinedomus.com" (e vice-versa). Uma pesquisa por "onlinedomus.com" irá mapear para o mesmo endereço IP.
/etc/resolv.conf
Este ficheiro contém a lista de servidores de DNS que serão usados para fazer pesquisas e eventualmente mais algumas opções (como timeouts para os pedidos, domínios que serão adicionados aos nomes pedidos caso o nome simples não obtenha resultados etc.). Um exemplo:

nameserver 192.168.112.2
nameserver 9.64.162.21

Como é que o Informix usa o DNS?

Da perspectiva do DNS, o Informix é apenas mais uma aplicação. O ficheiro /etc/nsswitch.conf contém configurações que definem se o Informix irá usar ficheiros (/etc/hosts) ou servidores de DNS (configurados em /etc/resolv.conf). A primeira coisa a notar é que toda a interacção do Informix com o DNS é feito através de funções de sistema. Em particular, o Informix usa duas funções ou as suas equivalente e/ou substitutas:

gethostbyname()
Resumidamente recebe um nome de máquina e retorna uma estrutura contendo um endereço IP
gethostbyaddr()
Esta faz o contrário, ou seja recebe uma estrutura com o endereço IP e retorna os campos relativos ao nome (ou nomes) preenchidos

Assim, se alguma coisa não estiver a funcionar, temos de entender quando e onde é que o Informix chama estas funções e como é que elas funcionam. É típico ver clientes a culpar o Informix quando tal não é justo (não completamente pelo menos, mas mais sobre isto adiante). A maioria (senão todos) dos problemas de DNS que afectam o Informix que presenciei, afectam também outras aplicações. E estes problemas são facilmente reproduzíveis com um pequeno programa em linguagem C. Quer isto dizer que não poderíamos fazer algumas coisas de forma diferente (melhor?) Não... Mas isto será abordado mais adiante (chamo a atenção para o termo de desresponsabilização :) )
Este artigo é escrito essencialmente da perspectiva do servidor de base de dados. Mas o DNS tem implicações óbvias no lado do cliente... Vamos começar por aqui e depois saltamos para o servidor.
Quando um cliente tenta conectar-se a um servidor Informix, começa por procurar o $INFORMIXSERVER (ou equivalente dado na string de conexão) no ficheiro $INFORMIXSQLHOSTS (em Java a informação pode ser obtida via LDAP ou HTTP, mas vamos assumir só ficheiros por simplificação). O ficheiro contém linhas com o seguinte formato:

INFORMIXSERVER PROTOCOLO NOME_MAQUINA/ENDERECO_IP NUMERO_PORTO/NOME_SERVICO OPCOES

Quando as funções das bibliotecas cliente encontram a linha que define o INFORMIXSERVER pretendido, obtêm o nome da máquina (ou endereço IP) e o número do porto (ou nome de serviço).
Se o nome de serviço é usado, procuramos o número do porto no ficheiro /etc/services (isto também pode ser configurado no /etc/nsswitch.conf). Pessoalmente habitualmente uso o número do porto directamente para evitar mais esta consulta..
Depois, se o nome de uma máquina foi usado, o cliente terá de o converter para um endereço IP. Para isso chama a função gethostbyname(). Esta função irá comportar-se como especificado no ficheiro /etc/nsswitch.conf e tentará mapear o nome recebido num endereço IP. Uma falha ao fazer isto irá resultar num erro -930. Isto pode ser provocado:

cheetah@pacman.onlinedomus.com:fnunes-> echo $INFORMIXSERVER; grep $INFORMIXSERVER $INFORMIXSQLHOSTS; dbaccess sysmaster -
blogtest
blogtest     onsoctcp     nowhere.onlinedomus.com 1500

930: Cannot connect to database server (nowhere.onlinedomus.com).
cheetah@pacman.onlinedomus.com:fnunes->

e se precisar de evidências do que se está a passar pode usar o strace (ou truss conforme a plataforma):

strace -o /tmp/strace.out dbaccess sysmaster -

O seguinte é um extracto editado do /tmp/strace.out gerado pelo comando acima. Se tiver paciência, pode vê-lo a fazer:

Abrir o ficheiro etc/nsswitch.conf
Abrir o ficheiro $INFORMIXSQLHOSTS (/home/informix/etc/sqlhosts)
Abrir o ficheiro /etc/services (excepcionalmente usei um nome em vez de um porto)
Abrir o /etc/resolv.conf para descobrir os servidores de DNS configurados
Abrir um socket para 192.168.112.2 (o servidor de DNS que tenho configurado)
Perguntar por nowhere.onlinedomus.com
Abrir o ficheir /etc/hosts (no /etc/nsswtich.conf eu configurei a pesquisa nos ficheiros após a pesquisa nos servidores de DNS)
Ler a mensagem de erro nos ficheiros de mensagens do Informix
Escrever a mensagem de erro no stderr
Sair com o erro -1

cheetah@pacman.onlinedomus.com:fnunes-> cat /tmp/strace.out
[...]
open("/etc/nsswitch.conf", O_RDONLY)    = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1803, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7862000
read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1803
read(3, "", 4096)                       = 0
close(3)                                = 0
[...]
open("/home/informix/etc/sqlhosts", O_RDONLY|O_LARGEFILE) = 4
_llseek(4, 0, [0], SEEK_SET)            = 0
read(4, "blogtest     onsoctcp     nowher"..., 4096) = 1389
[...]
open("/etc/services", O_RDONLY|O_CLOEXEC) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=644327, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7862000
read(4, "# /etc/services:\n# $Id: services"..., 4096) = 4096
close(4)                                = 0
[...]
open("/etc/resolv.conf", O_RDONLY)      = 4
[...]
read(4, "", 4096)                       = 0
close(4)                                = 0
[...]
open("/lib/libresolv.so.2", O_RDONLY)   = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0Pf\256\0004\0\0\0"..., 512) = 512
[...]
close(4)                                = 0
[...]
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
gettimeofday({1325590403, 502576}, NULL) = 0
poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
send(4, "tl\1\0\0\1\0\0\0\0\0\0\7nowhere\vonlinedomus"..., 41, MSG_NOSIGNAL) = 41
poll([{fd=4, events=POLLIN}], 1, 5000)  = 1 ([{fd=4, revents=POLLIN}])
ioctl(4, FIONREAD, [101])               = 0
recvfrom(4, "tl\201\203\0\1\0\0\0\1\0\0\7nowhere\vonlinedomus"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, [16]) = 101
close(4)                                = 0
[...]
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
[...]
read(4, "127.0.0.1\tpacman1.onlinedomus.ne"..., 4096) = 439
[...]
close(4)                                = 0
[...]
read(3, "Cannot connect to database serve"..., 40) = 40
write(2, "\n", 1)                       = 1
write(2, "  930: Cannot connect to databas"..., 68) = 68
exit_group(-1)                          = ?
cheetah@pacman.onlinedomus.com:fnunes->

Agora devemos passar para o lado do servidor. Mas isso requer um pouco mais de trabalho e explicações preliminares. Para começar temos de entender o que o motor necessita para estabelecer uma ligação ou sessão. Uma dessas coisas é fazer o chamado "reverse DNS" ou DNS inverso que não é mais que converter um endereço IP no nome de uma máquina. Isto pode não ser absolutamente essencial, mas é sempre tentado. O Informix pode precisar do nome da máquina para validar as relações de confiança (ligações sem utilizador/password). O nome servirá também para informação do DBA de forma a mais facimente identificar a origem do cliente.
Como saberá, o motor de base de dados Informix é composto por vários processos de sistema operativo. Do ponto de vista do SO, todos estes processos parecem iguais (chamam-se oninit), mas cada um tem um trabalho específico e corre threads específicas do motor.

Podemos listar as threads com:

panther@pacman.onlinedomus.com:fnunes-> onstat -g ath

IBM Informix Dynamic Server Version 11.70.UC4 -- On-Line -- Up 00:17:01 -- 411500 Kbytes

Threads:
 tid     tcb      rstcb    prty status                vp-class       name
 2       5583fa38 0        1    IO Idle                 3lio*        lio vp 0
 3       558551f8 0        1    IO Idle                 4pio*        pio vp 0
 4       5586b1f8 0        1    IO Idle                 5aio*        aio vp 0
 5       558811f8 8f59dc0  1    IO Idle                 6msc*        msc vp 0
 6       558af1f8 0        1    IO Idle                 7fifo*       fifo vp 0
 7       558c9590 0        1    IO Idle                 9aio*        aio vp 1
 8       558df3b8 54267018 3    sleeping secs: 1        8cpu         main_loop()
 9       559276f8 0        1    running                10soc*        soctcppoll
 10      5593ed18 0        2    sleeping forever        1cpu*        soctcplst
 11      55927d20 542675fc 1    sleeping secs: 1        8cpu         flush_sub(0)
 12      55988018 54267be0 1    sleeping secs: 1        8cpu         flush_sub(1)
 13      559881f0 542681c4 1    sleeping secs: 1        8cpu         flush_sub(2)
 14      559883c8 542687a8 1    sleeping secs: 1        8cpu         flush_sub(3)
 15      559885a0 54268d8c 1    sleeping secs: 1        8cpu         flush_sub(4)
 16      55988778 54269370 1    sleeping secs: 1        8cpu         flush_sub(5)
 17      55988bf0 54269954 1    sleeping secs: 1        8cpu         flush_sub(6)
 18      559fb468 54269f38 1    sleeping secs: 1        8cpu         flush_sub(7)
 19      559fb640 0        3    IO Idle                 8cpu*        kaio
 20      55ab6018 5426a51c 2    sleeping secs: 1        8cpu         aslogflush
 21      55ab6960 5426ab00 1    sleeping secs: 92       1cpu         btscanner_0
 22      55b6a408 5426b0e4 3    cond wait  ReadAhead    1cpu         readahead_0
 39      55bcd5c8 0        3    IO Idle                 1cpu*        kaio
 40      55bcd7a0 5426bcac 3    sleeping secs: 1        1cpu*        onmode_mon
 41      55d3e148 5426c874 3    sleeping secs: 1        8cpu         periodic
 49      55e80a78 5426da20 1    sleeping secs: 177      1cpu         dbScheduler
 51      55f340f8 5426d43c 1    sleeping forever        1cpu         dbWorker1
 52      55f34d80 5426ce58 1    sleeping forever        8cpu         dbWorker2
 59      562ee228 5426e5e8 1    cond wait  bp_cond      1cpu         bf_priosweep()

E os processos de sistema operativo com:

panther@pacman.onlinedomus.com:fnunes-> onstat -g glo

IBM Informix Dynamic Server Version 11.70.UC4 -- On-Line -- Up 00:18:48 -- 411500 Kbytes

MT global info:
sessions threads  vps      lngspins
0        29       10       3       

          sched calls     thread switches yield 0   yield n   yield forever
total:    9589515         8992470         597961    14485     4457836  
per sec:  0               0               0         0         0        

Virtual processor summary:
 class       vps       usercpu   syscpu    total   
 cpu         2         11.51     94.06     105.57  
 aio         2         3.57      75.44     79.01   
 lio         1         0.01      0.01      0.02    
 pio         1         0.00      0.01      0.01    
 adm         1         0.01      0.15      0.16    
 soc         1         0.04      0.15      0.19    
 msc         1         0.00      0.01      0.01    
 fifo        1         0.00      0.01      0.01    
 total       10        15.14     169.84    184.98  

Individual virtual processors:
 vp    pid       class       usercpu   syscpu    total     Thread    Eff  
 1     29395     cpu         5.63      46.80     52.43     66.41     78%
 2     29398     adm         0.01      0.15      0.16      0.00       0%
 3     29399     lio         0.01      0.01      0.02      0.02     100%
 4     29400     pio         0.00      0.01      0.01      0.01     100%
 5     29401     aio         3.29      74.30     77.59     77.59    100%
 6     29402     msc         0.00      0.01      0.01      0.03      31%
 7     29403     fifo        0.00      0.01      0.01      0.01     100%
 8     29404     cpu         5.88      47.26     53.14     64.45     82%
 9     29405     aio         0.28      1.14      1.42      1.42     100%
 10    29406     soc         0.04      0.15      0.19      NA         NA
                 tot         15.14     169.84    184.98

As threads que estão à escuta nos portos TCP do motor são as poll threads (soctcppoll) que correm nos VPs (virtual processors) de classe SOC (isto depende da configuração do parâmetro NETTYPE). Quando um novo pedido de ligação é recebido por elas, chama as listener threads (soctcplst) que correm na classe CPU, para iniciar o processo de autenticação. Partes deste processo são executadas pelo VP MSC. Como podemos ver na lista acima este tem o PID 29402. Portanto, para perceber o que se passa irei fazer o trace a este processo. Por razões que ficarão claras mais abaixo, vou desligar a funcionalidade NS_CACHE (11.7) e vou fazer uma paragem/arranque do motor. Após isto, para a primeira tentativa de conexão obtemos (algumas partes não relevantes foram cortadas):

1      0.000000 semop(753664, {{5, -1, 0}}, 1) = 0
2      7.009868 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
3      0.000107 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
4      0.000242 close(3)                  = 0
5      0.000060 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
6      0.000063 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
7      0.000095 close(3)                  = 0
8      [...]
9      0.000000 open("/etc/resolv.conf", O_RDONLY) = 3
10     0.000000 fstat64(3, {st_mode=S_IFREG|0644, st_size=55, ...}) = 0
11     0.000000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xab4000
12     0.000000 read(3, "# Generated by NetworkManager\nna"..., 4096) = 55
13     0.000926 read(3, "", 4096)         = 0
14     0.000050 close(3)                  = 0
15     [...]
16     0.000057 futex(0x29ab44, FUTEX_WAKE_PRIVATE, 2147483647) = 0
17     0.000256 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
18     0.000089 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
19     0.000107 gettimeofday({1325605320, 167025}, NULL) = 0
20     0.000072 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
21     0.000083 send(3, "\363\337\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
22     0.000322 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
23     2.061369 ioctl(3, FIONREAD, [121]) = 0
24     0.000111 recvfrom(3, "\363\337\201\203\0\1\0\0\0\1\0\0\0011\003112\003168\003192\7in-ad"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, [16]) = 121
25     0.000155 close(3)                  = 0
26     0.000090 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
27     0.000377 fstat64(3, {st_mode=S_IFREG|0644, st_size=439, ...}) = 0
28     0.000089 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf22000
29     0.000057 read(3, "127.0.0.1\tpacman1.onlinedomus.ne"..., 4096) = 439
30     0.000130 close(3)                  = 0
31     [...]
32     0.000072 semop(753664, {{7, 1, 0}}, 1) = 0
33     0.000069 semop(753664, {{7, 1, 0}}, 1) = 0
34     0.007558 semop(753664, {{5, -1, 0}}, 1

Note-se que para facilitar a análise, adicionei números de linhas e diferenças de tempos entre cada uma das chamadas a funções de sistema (isto será importante adiante). Vamos explicar o que vemos:

Na linha 1) tempos um semop() que é a forma de o VP MSC ficar inactivo, à espera de ser solicitado. Isto foi antes da tentativa de conexão
7 segundos depois, acorda e tenta "falar" com o serviço nscd (linhas 2-8). Este serviço é algo específico do Linux e eu não o tenho a correr. Depois acede a /etc/nsswitch.conf. Fixe que isto foi feito na primeira tentativa de conexão.
Depois acede ao ficheiro /etc/resolv.conf (linhas 9-15) e descobre os endereços IP dos servidores de DNS
Nas linhas 16-25 fala com o servidor de DNS (192.168.112.2) e pede o nome do endereço IP que se está a tentar ligar (obtido pela estrutura do socket)
Como a resposta é inconclusiva, vai ao ficheiro /etc/hosts (linhas 26-31)
Cortei a parte restante, relativa à autenticação (abertura do /etc/passwd, /etc/group e /etc/shadow etc.)
Finalmente retorna ao normal estado de espera

Alguns pontos importantes sobre isto:

Tudo aconteceu bastante depressa (valores em segundos)
Não vemos a chamada à função gethostbyaddr() que eu garanti que era chamada pelo Informix. Na perspectiva do strace esta não é uma "system call". Só vemos chamadas de mais baixo nível, mas não a gethostbyaddr(). Podemos apanhá-la se ligar-mos um debugger (dbx, gdb, adb) ao processo. Isto é importante, pois é habitual ser difícil discutir este tema com os administradores de rede e sistema operativo, pois pensam que todas estas chamadas são feitas pelo Informix. Não são! O Informix apenas chama a gethostbyaddr() ou equivalente

Agora vamos ver o mesmo processo, mas para a segunda tentativa de conexão. Seria de esperar que o resultado fosse o mesmo, mas não é. Cortei exactamente as mesmas zonas:

1      0.000000 semop(753664, {{5, -1, 0}}, 1) = 0
2      6.452154 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
3      0.000099 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
4      0.008816 gettimeofday({1325605445, 534040}, NULL) = 0
5      0.000089 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
6      0.000100 send(3, "\233\t\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
7      0.000417 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
8      2.089726 ioctl(3, FIONREAD, [121]) = 0
9      0.000118 recvfrom(3, "\233\t\201\203\0\1\0\0\0\1\0\0\0011\003112\003168\003192\7in-ad"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, [16]) = 121
10     0.000132 close(3)                  = 0
11     0.000069 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
12     0.000102 fstat64(3, {st_mode=S_IFREG|0644, st_size=439, ...}) = 0
13     0.000092 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xe1f000
14     0.000064 read(3, "127.0.0.1\tpacman1.onlinedomus.ne"..., 4096) = 439
15     0.000099 close(3)                  = 0
16     [...]
17     0.000068 semop(753664, {{0, 1, 0}}, 1) = 0
18     0.000096 semop(753664, {{0, 1, 0}}, 1) = 0
19     0.000076 semop(753664, {{5, -1, 0}}, 1

Novamente a análise:

A primeira parte de acesso ao servilo nscd, a abertura do /etc/nsswitch.conf e do /etc/resolv.conf não aparece. Como se pode ver começa logo com a consulta ao DNS
Depois lê o ficheiro /etc/hosts
Voltei a cortar a parte da autenticação como anteriormente
Finalmente regressa ao estado de espera, tal como anteriormente

O ponto importante a reter é que a primeira tentativa é diferente das subsequentes. E reforço novamente que o Informix apenas chama a gethostbyaddr()... exactamente a mesma chamada de cada vez. Bom... para ser exacto a função que chamamos pode depender da plataforma, mas é sempre a mesma em cada conexão. Como referi acima, apenas com a utilização de um debugger podemos capturar a chamada à gethostbyaddr(). Eu fi-lo e aqui está o resultado:

(gdb) break connect
Breakpoint 1 at 0x95f640
(gdb) continue
Continuing.

Breakpoint 1, 0x0095f640 in connect () from /lib/libpthread.so.0
(gdb) where
#0  0x0095f640 in connect () from /lib/libpthread.so.0
#1  0x00aec9ab in reopen () from /lib/libresolv.so.2
#2  0x00aee542 in __libc_res_nsend () from /lib/libresolv.so.2
#3  0x00aeb24e in __libc_res_nquery () from /lib/libresolv.so.2
#4  0x002b6dc7 in _nss_dns_gethostbyaddr2_r () from /lib/libnss_dns.so.2
#5  0x002b6f1a in _nss_dns_gethostbyaddr_r () from /lib/libnss_dns.so.2
#6  0x0020890b in gethostbyaddr_r@@GLIBC_2.1.2 () from /lib/libc.so.6
#7  0x00211f77 in getnameinfo () from /lib/libc.so.6
#8  0x08c0e664 in ifx_getipnodebyaddr ()
#9  0x08c0f79c in ifx_gethostbyaddr ()
#10 0x08c0f8a2 in __osgethostbyaddr ()
#11 0x08b0c055 in aio_workon ()
#12 0x08b0c9c3 in aiothread ()
#13 0x08b0dbcb in iothread ()
#14 0x08b00762 in startup ()
#15 0x558749e8 in ?? ()
#16 0x00000000 in ?? ()
(gdb)

Como pode ver, estabeleci um breakpoint na função connect(). Depois executei o continue para que o processo prosseguisse e tentei a conexão. O debugger interrompeu a execução quando chegou ao connect() e isso permitiu-me retirar um stack trace (ler de baixo para cima)
Portanto, mostra-nos que chamamos a função getnameinfo() que por sua vez chama a gethostbyaddr_r() etc. Tudo isto está contido em bibliotecas de sistema, não no código Informix.

Há mais dois pontos a salientar. Primeiro, o processador virtual do Informix da classe MSC processa os pedidos de forma sequencial. Para cada conexão é-lhe pedido que efectue o DNS inverso (pedindo aos servidores DNS ou lendo o ficheiro /etc/hosts) e faça a autenticação. Por omissão apenas temos um MSC... portanto se um pedido ficar "preso"... sim... os que vierem a seguir irão sofrer atrasos. Estes atrasos podem ser uma fracção de segundo ou alguns segundos, mas em alguns sistemas já observei dezenas de conexões por segundo (já vi referências a centenas/segundo). Portanto mesmo um atraso de alguns segundos pode ter um impacto muito notório.
O segundo ponto refere-se à diferença entre a primeira chamada e as seguintes. Como vimos acima, na primeira chamada é verificada a configuração (ficheiros /etc/nsswitch.conf e /etc/resolv.conf). Nas seguintes tal não acontece por razões de performance. E isto causa um problema. Novamente, este comportamento é das funções de sistema, não do Informix (mas não será necessariamente o fim da história)

Portanto, espero que tenha conseguido explicar como é que o Informix interage com o sistema de DNS. O mergulho nos bits e bytes já terminou. Vamos prosseguir para as implicações, mas é importante que tenha ficado claro o que foi explicado acima antes de prosseguir para os próximos parágrafos.

Que problemas podemos enfrentar?

Acima tentei demonstrar como as coisas funcionam quando está tudo ok. Mas o que acontece quando algo está mal? Vamos ver o que pode correr mal e quais as implicações. Tentarei também tentar indicar de quem será a responsabilidade (mais uma vez relembro o termo de desresponsabilização...). O objectivo não é propriamente apontar o dedo a ninguém, mas saber onde é que o problema reside é meio caminho andado para o resolver.

Problemas de rede impedem a conexão aos servidores de DNS
Se isto acontecer, os pedidos enviados pelo VP MSC terão de dar timeout (tipicamente alguns segundos) antes que as chamadas às funções de sistema operativo retornem. Este atraso irá causar que todos os pedidos de conexão seguintes fiquem em espera (assumindo que só temos um MSC VP). Se os problemas de rede persistirem, não irá importar muito quantos processadores de classe MSC temos, pois à partida todos eles irão ficar presos e todos os pedidos de conexão sofrerão atrasos.
O(s) servidor(es) de DNS caem, são parados ou ficam muito lentos
O efeito disto é em tudo semelhante ao anterior. Qualquer coisa que cause atrasos nos pedidos aos DNS irá potenciar atrasos nas conexões ao motor. Note-se que isto pode ser um problema que afecte todos os pedidos, ou apenas alguns. Devido à natureza hierárquica e distribuída da estrutura de DNS, pode ser possível responder a alguns pedidos e não a outros por estes levarem a contactos com determinados servidores que possam não estar disponíveis. Escusado referir que isto torna a investigação destes problemas ainda mais difícil.
Algo afecta o sistema de DNS. Os pedidos de DNS inverso falham e isto afecta as conexões trusted
Neste caso começam a aparecer erros -956 no online.log da instância e os clientes começam a receber o erro -951. Naturalmente isto acontece se as relações de confiança estiverem definidas com nomes em vez de endereços IP (o uso de nomes é o mais normal e recomendado, dado que é mais frequente mudar um IP que o nome)
Precisa de mudar os seus servidores de DNS
Então terá de parar e arrancar o Informix. Isto é um problema causado pelo Informix (podía-mos fazer melhor). Como referido acima, as funções de sistema operativo fazem cache da configuração (seria muito ineficiente re-verificar a configuração em cada pedido). E esta situação leva a que o Informix não se "aperceba" que os servidores de DNS foram mudados. Portanto o problema é que se mudarmos a politica de resolução (/etc/nsswitch.conf) ou os servidores (/etc/resolv.conf) os processos de Informix não terão isso em conta

Dos problemas acima é fácil de entender que os três primeiros não são "culpa" do Informix. Quando um cliente decide usar uma infra-estrutura de DNS (supostamente porque necessita) terá de entender que isso passa automaticamente a ser um componente critico dos seus sistemas. Qualquer problema que essa infra-estrutura tenha vai afectar as camadas acima como os servidores de base de dados e outros.
E assim ficamos com o quarto problema. Escrevi atrás e é verdade que o comportamento é das funções de sistema operativo (e vou demonstrá-lo), portanto porque é que digo que a responsabilidade é do Informix? Bom, porque existe uma forma de lidar com isto. Há uma outra função de sistema chamada res_init() que faz aquilo que necessitamos. Do manual de Linux, cito (sem tradução):

The res_init() function reads the configuration files (see resolv.conf(5)) to get the default domain name, search order and name server address(es).
If no server is given, the local host is tried. If no domain is given, that associated with the local host is used. It can be overridden with the environment variable LOCALDOMAIN. res_init() is normally executed by the first call to one of the other functions.

A minha opinião é que o Informix deveria providenciar uma forma pela qual o DBA poderia forçar que cada processador virtual da classe MSC chamasse esta função. Isto refrescaria a informação obtida na primeira chamada à gethostbyaddr() que é mantida em cache no espaço do processo.
Na verdade a IBM tem um pedido de funcioalidade pendente que refer isto explicitamente. Gostaria bastante de o ver implementado numa versão futura. Isto é algo sem o qual podemos viver durante anos, mas se a situação se coloca pode realmente fazer a diferença entre ter de parar o servidor de base de dados ou não.

Detectar se temos um problema

Como podemos saber se temos um problema de DNS e isso está a ter impacto no Informix? Habitualmente iremos receber algum tipo de queixa dos clientes/aplicações Informix. Tipicamente algo como "a base de dados está muito lenta", ou algo mais correcto como "leva muito tempo a estabelecer uma conexão", ou eventualmente algumas sessões serão recusadas com o erro -956 (do lado do servidor) que corresponde a um erro -951 retornado ao cliente. Nos casos mais extremos podem aparecer erros menos comuns no online.log (-25xxx). Em todos estes casos notará que depois de estabelecidas as ligações estas trabalham sem problemas.
Mas para ter a certeza absoluta pode seguir dois caminhos:

O mais simples é correr um simples "netstat -a" na máquina onde reside o servidor de base de dados. Isto mostra todas as ligações TCP/UDP de e para a máquina. Por omissão, vai percorrer todas as ligações socket e tentará fazer o pedido de DNS inverso sobre o respectivo endereço IP para obter os nomes das máquinas. Se estiver a ter problemas de DNS o netstat irá correr muito lento ou pelo menos verificará alguns "soluços" no output do mesmo. Mas para que este teste seja conclusivo, tem de garantir que as configurações de DNS que o netstat vai usar são as mesmas que o motor Informix está a usar (que serão as que tinha quando o motor foi levantado)
O mais complexo passa por executar um comando "truss" ou "strace" contra o(s) processo do processador virtual de classe MSC, com apresentação de tempos. Isto permitirá mostrar tempos de resposta lentos das funções que trocam informação com os servidores de DNS. Tenha em atenção que correr o truss/strace requer privilégios de root e que mesmo quando tudo está a correr bem, isto causará algum impacto em sistemas com uma taxa de novas ligações por segundo elevada.

Escrevia atrás que posso demonstrar os factos apresentados aqui sem usar o Informix. Para tal criei um pequeno programa em C (números de linha adicionados):

1  #include <sys/time.h>
2  #include <netdb.h>
3  #include <resolv.h>
4  #include <stdlib.h>
5  #include <string.h>
6  
7  int main(int argc, char **argv)
8  {
9    struct hostent *hp;
10    in_addr_t data;
11    char buff[100];
12    struct timeval ts_initial, ts_final;
13  
14    if (argc == 2) {
15      strcpy(buff,argv[1]);
16    }
17    else {
18      printf("Introduce an IP address: ");
19      if (fscanf(stdin,"%s", buff) == EOF)
20        exit(0);
21    }
22  
23    while (1 == 1) {
24      data = inet_addr(buff);
25      gettimeofday(&ts_initial, NULL);
26      hp = gethostbyaddr(&data, 4, AF_INET);
27      gettimeofday(&ts_final, NULL);
28  
29      if (hp == NULL) {
30        printf("Unknown host (%s). Took %f seconds\n", buff, (double)((ts_final.tv_sec * 1000000 + ts_final.tv_usec) - (ts_initial.tv_sec * 1000000 + ts_initial.tv_usec))/1000000);
31      }
32      else {
33        printf("Name (%s): %s Took %f seconds\n", buff, hp->h_name, (double)((ts_final.tv_sec * 1000000 + ts_final.tv_usec) - (ts_initial.tv_sec * 1000000 + ts_initial.tv_usec))/1000000);
34      }
35      printf("Next: ");
36      if (fscanf(stdin,"%s", buff) == EOF)
37        exit(0);
38      if ( strncmp("refresh", buff, 7) == 0 )
39      {
40         res_init();
41         printf("Called res_init()\n");
42         printf("Next: ");
43         if (fscanf(stdin,"%s", buff) == EOF)
44           exit(0);
45      }
46    }
47  }

Isto é basicamente um ciclo que lê um endereço IP (que não é validado, portanto é fácil de causar erros no programa) e corre a gethostbyaddr() sobre o mesmo. Se o "IP" dado fôr "refresh" então chama a função res_init(). Informa das respostas obtidas pelo sistema de resolução de nomes e o tempo que demorou. Pode ser usado interactivamente ou podemos chamá-lo redireccionando o input de um ficheiro que contenha um endereço IP em cada linha.

Vou executá-lo interactivamente com tracing para mostrar o efeito de chamar a função res_init(). Tenho "hosts: dns, files" no ficheiro /etc/nsswitch.conf e 192.168.112.2 no /etc/resolv.conf. Este último contém também opções para definir um timeout de 2 segundos. Portanto chamo-o com:

cheetah@pacman1.onlinedomus.net:fnunes-> strace -r -o test_resolv.trace ./test_resolv
Introduce an IP address: 1.1.1.1
Unknown host (1.1.1.1). Took 2.010235 seconds
Next: 1.1.1.2
Unknown host (1.1.1.2). Took 2.003324 seconds
Next: refresh
Called res_init()
Next: 1.1.1.3
Unknown host (1.1.1.3). Took 2.004002 seconds
Next: ^C

Antes de introduzir "refresh" mudo o servidor de DNS no ficheiro /etc/resolv.conf de 192.168.112.2 para 192.168.112.5.
O resultado do trace é este (números de linha e tempos adicionados):

1        [...]
2        0.000000 write(1, "Introduce an IP address: ", 25) = 25
3        0.000000 read(0, "1.1.1.1\n", 1024) = 8
4        3.055699 gettimeofday({1325865284, 104186}, NULL) = 0
5        [...]
6        0.000160 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
7        0.000099 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
8        0.000128 close(3)                  = 0
9        0.000053 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
10       0.000123 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
11       0.000122 close(3)                  = 0
12       0.000095 open("/etc/nsswitch.conf", O_RDONLY) = 3
13       0.000108 fstat64(3, {st_mode=S_IFREG|0644, st_size=1803, ...}) = 0
14       0.000101 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
15       0.000057 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1803
16       0.000001 read(3, "", 4096)         = 0
17       0.000000 close(3)                  = 0
18       [...]
19       0.000055 open("/etc/resolv.conf", O_RDONLY) = 3
20       0.000072 fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
21       0.000095 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
22       0.000050 read(3, "# Generated by NetworkManager\nna"..., 4096) = 118
23       0.000086 read(3, "", 4096)         = 0
24       0.000046 close(3)                  = 0
25       [...]
26       0.000173 open("/etc/host.conf", O_RDONLY) = 3
27       0.000068 fstat64(3, {st_mode=S_IFREG|0644, st_size=26, ...}) = 0
28       0.000081 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
29       0.000179 read(3, "multi on\norder hosts,bind\n", 4096) = 26
30       0.000083 read(3, "", 4096)         = 0
31       0.000048 close(3)                  = 0
32       0.000049 munmap(0xb7843000, 4096)  = 0
33       0.000160 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
34       0.000075 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
35       0.000640 gettimeofday({1325865284, 108850}, NULL) = 0
36       0.000062 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
37       0.000094 send(3, "r\363\1\0\0\1\0\0\0\0\0\0\0011\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
38       0.000889 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
39       2.003373 close(3)                  = 0
40       0.000109 open("/etc/ld.so.cache", O_RDONLY) = 3
41       0.000078 fstat64(3, {st_mode=S_IFREG|0644, st_size=72238, ...}) = 0
42       0.000093 mmap2(NULL, 72238, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7821000
43       0.000054 close(3)                  = 0
44       [...]
45       0.000105 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
46       0.000097 fcntl64(3, F_GETFD)       = 0x1 (flags FD_CLOEXEC)
47       0.000065 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
48       0.000053 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
49       0.000035 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
50       0.000137 read(3, "", 4096)         = 0
51       0.000130 close(3)                  = 0
52       [...]
53       0.000101 write(1, "Unknown host (1.1.1.1). Took 2.0"..., 46) = 46
54       0.000071 write(1, "Next: ", 6)     = 6
55       0.000267 read(0, "1.1.1.2\n", 1024) = 8
56       0.000071 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
57       0.000077 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
58       0.000049 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
59       0.000063 send(3, ":\243\1\0\0\1\0\0\0\0\0\0\0012\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
60       0.000152 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
61       2.002550 close(3)                  = 0
62       0.000088 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
63       0.000077 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
64       0.000092 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
65       0.000057 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
66       0.000110 read(3, "", 4096)         = 0
67       0.000049 close(3)                  = 0
68       [...]
69       0.000060 write(1, "Unknown host (1.1.1.2). Took 2.0"..., 46) = 46
70       0.000076 write(1, "Next: ", 6)     = 6
71       0.000253 read(0, "refresh\n", 1024) = 8
72      17.639011 open("/etc/resolv.conf", O_RDONLY) = 3
73       0.000088 fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
74       0.000087 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
75       0.000052 read(3, "# Generated by NetworkManager\n#n"..., 4096) = 118
76       0.000108 read(3, "", 4096)         = 0
77       0.000047 close(3)                  = 0
78       0.000048 munmap(0xb7843000, 4096)  = 0
79       0.000065 write(1, "Called res_init()\n", 18) = 18
80       0.000060 write(1, "Next: ", 6)     = 6
81       0.000051 read(0, "1.1.1.3\n", 1024) = 8
82       3.595382 gettimeofday({1325865312, 174933}, NULL) = 0
83       0.000075 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
84       0.000078 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.5")}, 16) = 0
85       0.000266 gettimeofday({1325865312, 175350}, NULL) = 0
86       0.000052 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
87       0.000069 send(3, "\321\234\1\0\0\1\0\0\0\0\0\0\0013\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
88       0.000085 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
89       2.002271 close(3)                  = 0
90       0.000081 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
91       0.000076 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
92       0.000087 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
93       0.000054 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
94       0.000091 read(3, "", 4096)         = 0
95       0.000047 close(3)                  = 0
96       0.000048 munmap(0xb7843000, 4096)  = 0
97       0.000062 gettimeofday({1325865314, 178373}, NULL) = 0
98       0.000058 write(1, "Unknown host (1.1.1.3). Took 2.0"..., 46) = 46
99       0.000072 write(1, "Next: ", 6)     = 6
100      0.000053 read(0, 0xb7844000, 1024) = ? ERESTARTSYS (To be restarted)
101      0.918564 --- SIGINT (Interrupt) @ 0 (0) ---
102      0.000931 +++ killed by SIGINT +++

E a explicação:

Linhas 1-5 o programa arranca e pede o endereço IP. Dou-lhe 1.1.1.1
Linhas 6-18 tenta contactar o serviço nscd (serviço de caching em Linux) e depois abre e lê o ficheiro /etc/nsswitch.conf
Linhas 19-31 abre os outros dois ficheiros de configuração (/etc/resolv.conf e /etc/host.conf)
Linhas 33-44 contacta o servidor de DNS em 192.168.112.2 (timeout = 2s)
Linhas 45-52 lê /etc/hosts e imprime o resultado (Unknown host)
Linhas 53-68 é o mesmo, mas não lê os ficheiros de configuração pois já não é o primeiro pedido
Linhas 69-79 eu insiro "refresh" e o programa chama a res_init() e re-lê o /etc/resolv.conf. Entretanto, antes eu mudo no /etc/resolv.conf o servidor DNS para 192.168.112.5
Linhas 80-99 I insiro outro endereço IP (1.1.1.3) e vai contactar o novo servidor de DNS (192.168.112.5). Ao não obter uma resposta, re-lê o /etc/hosts.
Linhas 100-102 estava a pedir novamente um endereço IP e pressiono Control+C

Hacking só por brincadeira!

Por favor não tente isto em casa! Atenção, o que vem a seguir é arriscado, não suportado e apresentado apenas para provar um ponto de vista. Argumentei acima que chamar a função res_init() permitiria que se mudasse os endereços dos servidores DNS sem parar e arrancar o Informix. Vamos prová-lo!
Fiz novamente trace a uma conexão, olhando para o processo do processador virtual da classe MSC. Obtive isto:

socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
gettimeofday({1326038028, 174740}, NULL) = 0
poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])
send(3, "+\316\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
poll([{fd=3, events=POLLIN}], 1, 2000)  = 0 (Timeout)
close(3)                                = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x12f000
read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
close3)

Está a ligar-se ao 192.168.112.2, que é o servidor DNS definido no /etc/resolv.conf. Se eu mudar isso no ficheiro para 192.168.112.5 e tentar novamente, acontece o mesmo (não se apercebe da mudança). Mas agora, sem mais alterações no ficheiro, se correr um debugger contra o processo do MSC:

[root@pacman tmp]# gdb -p 4649
GNU gdb (GDB) Fedora (7.1-18.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http: bugs="" gdb="" software="" www.gnu.org="">.
Attaching to process 4649
Reading symbols from /usr/informix/srvr1170uc4/bin/oninit...(no debugging symbols found)...done.
[...]
(gdb) call __res_init()
$1 = 0
(gdb) detach
Detaching from program: /usr/informix/srvr1170uc4/bin/oninit, process 4649
(gdb) quit
[root@pacman tmp]#

Se fizer um "call", ou seja chamar a função, a __res_init() que verifiquei ser o nome interno da função definida na libc.so e fizer um novo trace a uma conexão obtenho:

socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.5")}, 16) = 0
gettimeofday({1326038409, 784712}, NULL) = 0
poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])
send(3, "\364K\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
poll([{fd=3, events=POLLIN}], 1, 2000)  = 0 (Timeout)
close(3)                                = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x12f000
read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
close(3)

Ups! Hacked!... Claro que isto não é suportado. Não tente isto numa instância "real". Apenas serve para provar uma teoria.

Conclusões

O que tentei demonstrar neste artigo é como o Informix interage com os serviços de DNS, se os mesmos estiverem configurados no seu ambiente. Espero ter deixado claro que uma vez activo, o DNS toma um papel muito importante no estabelecimento de ligações. Tanto que um mau funcionamento do DNS terá um impacto muito significativo no sistema de gestão de base de dados. Há alguns pontos em que se pode atribuir responsabilidade ao Informix. Em particular:

O facto de os pedidos de DNS inverso serem feitos pelo processador virtual da class MSC pode gerar atrasos em pedidos que poderiam correr bem, apenas porque um pedido anterior teve um problema. Ter mais de um processador virtual MSC pode aliviar isto significativamente, mas poderá não resolver por completo
O facto de o Informix não estabelecer timeouts na chamada à gethostbyaddr() - ou equivalente -pode também causar atrasos desnecessários. Mas note-se que a assinatura das funções não tem nada que o permita, e portanto seria necessário criar um alarme que enviasse um sinal ao processo, e que este verificasse se ainda estava à espera da chamada. Isto traria um peso adicional que não faz muito sentido, especialmente quando os timeouts podem ser configurados na configuração geral dos servidores de DNS
O facto de as funções chamadas fazerem cache das configurações, aliado ao facto de o Informix não proporcionar uma forma de limpar essa cache (havendo funcionalidades de baixo nível que o permitem), significa que uma mudança nos endereços de DNS requerem uma paragem e arranque do motor Informix. Existe um pedido de funcionalidade registado para isto e muito me agradaria que fosse implementado

Por outro lado, o Informix 11.7 introduziu uma excelente funcionalidade que permite aliviar quase todos os problemas.Com o parâmetro NS_CACHE podemos configurar tempos de caching para vários sistemas (DNS, utilizadores/passwords, serviços...). Isto pode reduzir ao mímino o número de pedidos que são feitos. Naturalmente sempre que lidamos com caches temos o risco de lidar com informação desactualizada, mas neste caso limpar as caches é tão simples quanto correr o comando "onmode -wm NS_CACHE=..." e indicar um timeout de zero segundos. Já agora, este seria um bom sitio/momento para forçar a chamada da função res_init()...

Para fechar o artigo gostaria de mencionar algumas boas práticas:

Usar o Informix 11.7 se possível, para que possa tirar proveito do sistema de caching. Os administradores de sistema e/ou de DNS irão apreciar isto se tiver uma taxa de novas ligações muito alta
Considerar incluir "files" no ficheiro de configuração /etc/nsswitch.conf. Algumas pessoas podem considerar isto uma má ideia, pois pode causar muita actividade sobre o ficheiro /etc/hosts. Mas se as consultas ao ficheiro só forem feitas se os DNS não responderem, e o ficheiro fôr mantido com poucas entradas, e idealmente se usar o sistema de cache do Informix 11.7 o impacto adicional será negligenciável. E isto pode salvá-lo, caso tenha problemas nos DNS, pois temporariamente poderia adicionar entradas a este ficheiro, permitindo assim que a resolução de nomes fosse feita. Note que pelo menos no meu sistema de testes (Linux), mesmo a chamada à função res_init() não força a leitura novamente do ficheiro /etc/nsswitch.conf
Faça com que os seus administradores de DNS e os DBAs se entendam... Terão de trabalhar em conjunto e têm de entender que os seus serviços estão intimamente ligados
Use o Informix 11.7 se puder, para que possa usar o parâmetro REMOTE_SERVER_CFG. Em muitas empresas os DBAs não têm permissões para gerir o /etc/hosts.equiv (ficheiro de sistema). Se tiver um problema de DNS que impossibilite as conversões de endereços IP em nomes, as suas relações de confiança irão ser afetadas se estiverem definidas com nomes.e não endereços (o normal). Numa situação de emergência poderá ser útil que o DBA possa agir imediatamente e temporariamente adicionar os endereços IP ao ficheiro que estabelece as reações de confiança. Com o REMOTE_SERVER_CFG isso será possível sem privilégios de administrador de sistema
Use timeouts configurados no /etc/resolv.conf baixos de forma a que o tempo inútil de espera seja menor (uma consulta a um DNS é algo muito rápido)

Small query performance analysis / Pequena análise de performance de querys

2011-12-22T00:15:00.000Z

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

The need...

The end of the year is typically a critical time for IT people. Following up on last article's I'm still working with performance issues. "Performance issues on Informix?!" I hear you say... Well yes, but to give you an idea of the kind of system I'm talking about I can say that recently we noticed three small tables (between 3 and 60 rows) that between mid-night and 11AM were scanned 33M times. To save you the math, that's around 833 scans/queries for each of these tables per second. And this started to happen recently, on top of the normal load that nearly 3000 sessions can generate...
So, the point is: every bit of performance matters. And in most cases, on this system there are no long running queries. It's mostly very short requests made an incredible number of times. And yes, this makes the DBA life harder... If you have long running queries with bad query plans they're usually easy to spot. But if you have a large number of very quick queries, but with questionable query plans, than it's much more difficult to find.

Just recently I had one of this situations. I've found a query with a questionable query plan. The query plan varies with the arguments and both possible options have immediate response times (fraction of a second). That's not the first time I've found something similar, and most of the times I face the same situation twice I usually decide I need to have some tool to help me on that.

The idea!

The purpose was to see the difference in the work the engine does between two query plans. And when I say "tool" I'm thinking about a script. Last time I remember having this situation, I used a trick in dbaccess to obtain the performance counters for both the session, and the tables involved. Some of you probably know, others may not, but when dbaccess parses an SQL script file it can recognize a line starting with "!" as an instruction to execute the rest of the line as a SHELL command. So basically what I did previously was to customize the SQL script containing the query like this:

!onstat -z

SELECT .... FROM .... WHERE ...

!some_shell_scritpt

where some_shell_script had the ability to find the session and run an onstat -g tpf and also an onstat -g ppf. These two onstat commands show us a lot of performance counters respectively from the threads (tpf) and from the partitions (ppf). The output looks like:

IBM Informix Dynamic Server Version 11.70.UC4 -- On-Line -- Up 7 days 23:42:15 -- 411500 Kbytes

Thread profiles
tid lkreqs lkw dl to lgrs isrd iswr isrw isdl isct isrb lx bfr bfw lsus lsmx seq
24  0      0   0  0  0    0    0    0    0    0    0    0  0   0   0    0    0  
26  0      0   0  0  0    0    0    0    0    0    0    0  95  95  0    0    0  
51  32917  0   0  0  21101 13060 3512 57   532  3795 0    0  91215 29964 0    125008 4226
52  39036  0   0  0  9099 11356 2648 80   1372 265  0    0  45549 9312 0    244900 21 
49  705    0   0  0  574  8938 0    139  0    139  0    0  22252 148 0    5656 541
2444 706    0   0  0  14   344  0    4    0    0    3    0  819 7   136  224  0

This tells us the thread Id, lock requests, lock waits, deadlocks, timeouts, logical log records, isam calls (read, write, rewrite, delete, commit and rollback), long transactions, buffer reads and writes, logical log space used, logical log space maximum and sequential scans.
And this:

panther@pacman.onlinedomus.com:informix-> onstat -g ppf | grep -v "0     0     0     0     0     0     0     0     0     0     0     0"

IBM Informix Dynamic Server Version 11.70.UC4 -- On-Line -- Up 7 days 23:43:41 -- 411500 Kbytes

Partition profiles
partnum    lkrqs lkwts dlks  touts isrd  iswrt isrwt isdel bfrd  bfwrt seqsc rhitratio
0x100001   0     0     0     0     0     0     0     0     13697 0     0     100
0x100002   993   0     0     0     445   0     0     0     1460  0     2     100
0x10002d   6769  0     0     0     2379  34    340   34    9094  581   2     100
0x10002e   164   0     0     0     166   0     0     0     472   0     2     100
0x10002f   2122  0     0     0     2750  0     0     0     5288  0     0     100
0x100030   0     0     0     0     4     0     0     0     700   0     4     100
0x100034   14192 0     0     0     5922  192   80    192   15566 1274  0     100
0x100035   2260  0     0     0     188   80    0     80    2766  655   4     100
0x100036   1350  0     0     0     548   34    0     34    1872  249   0     100
0x100037   80    0     0     0     16    4     0     4     346   28    0     100
0x100038   4720  0     0     0     738   360   0     360   3734  1557  0     100

which tells us some of the above, but for each partition.
Note that I reset the counters, run the query and then obtain the profile counters. Ideally, nothing else should be running on the instance (better to do it on a test instance)

Sharing it

But I decided to make this a bit easier and I created a script for doing it. I'm also using this article to announce that starting today, I'll try to keep my collection of scripts on a publicly available site:

http://onlinedomus.com/informix/viewvc.cgi

This repository contains a reasonable amount of scripts for several purposes. Ideally I should create proper documentation and use cases for each one of them, but I currently don't have that. It's possible I'll cover some of them here in the blog, but probably only integrated in a wider article (like this one).

These scripts were created by me (with one exception - setinfx was created by Eric Vercelleto when we were colleagues in Informix Portugal and we should thank him for allowing the distribution), during my free time and should all contain license info (GPL 2.0). This means you can use them, copy them, change them etc. Some of them are very old and may not contain this info.
Some fixes and improvements were done during project engagements. Many of them were based on ideas I got from some scripts available in IIUG's software repository or from colleagues ideas, problems and suggestions (Thanks specially to António Lima and Adelino Silva)

It's important to notice that the scripts are available "as-is", no guarantees are made and I cannot be held responsible for any problem that it's use may cause.
Having said that, I've been using most of them on several customers for years without problems.
Any comments and/or suggestions are very welcome, and if I find the suggestions interesting and they don't break the script's ideas and usage, I'll be glad to incorporate them on future versions.

Many of the scripts have two option switches that provide basic help (-h) and version info (-V).
If by any chance you are using any of these scripts I suggest you check the site periodically to find any updates. I try my best to maintain retro-compatibility and old behavior when I make changes on them.

Back to the problem

So, this article focus on analyzing and comparing the effects of running a query with two (or more) different query plans. The script created for this was ixprofiling. If you run it with -h (help) option it will print:

panther@pacman.onlinedomus.com:fnunes-> ./ixprofiling -h
ixprofiling [ -h | -V ]
            -s SID database
            [-z|-Z|-n] database sql_script
     -h             : Get this help
     -V             : Get script version
     -s SID database: Get stats for session (SID) and database
     -n             : Do NOT reset engine stats
     -z             : Reset engine stats using onstat (default - needs local database)
     -Z             : Reset engine stats using SQL Admin API (can work remotely )

Let's see what the options do:

-s SID database
Shows the info similar to onstat -g tpf (for the specified session id) and onstat -g ppf (for the specified database)
It will show information for all the partition objects in the specified database for which any of the profile counters is different from zero. Note that when I write partition, it can be a table, a table's partition or a table's index.
database sql_script
Runs the specified SQL script after making some changes that will (by default) reset the engine profile counters (-z option). See more information about the SQL script below
-n
Prevents the reset of profile counters (if you're not a system database administrator you'll need to specify this to avoid errors)
-z
Resets the profile counters using onstat -z. This is the quickest and most simple way to do it but will need local database access.
-Z
Resets the counters using SQL admin API, so it can be used on remote databases

And now let's see an usage example. The script has some particularities that need to be detailed.
First, since the idea is to compare two or more query plans we can put all the variations inside the SQL script, separating them by a line like:

-- QUERY

when the script finds these lines, it will automatically get the stats (from the previous query) and reset the counters to prepare for the next query. If you use just one query you don't need this, since by default it will reset the counters at the beginning and show the stats at the end.
If you put two or more queries on the script don't forget to end each query with ";" or it will break the functionality.
Let's see a practical example. I have a table with the following structure:

create table ibm_test_case 
  (
    col1 integer,
    col2 smallint not null ,
    col3 integer,
    col4 integer,
[... irrelevant bits... ]
    col13 datetime year to second,
[... more irrelevant bits... ]
  );

create index ix_col3_col13 on ibm_test_case (col3,col13) using btree ;
create index ix_col4 on ibm_test_case (col4) using btree ;

and a query like:

select c.col1
from ibm_test_case c
where
        c.col3 = 123456789 and
        c.col4 = 1234567 and
        c.col13 = ( select max ( c2.col13 ) from ibm_test_case c2
                where
                        c2.col3 = c.col3 and
                        c2.col4 = c.col4
                );

The problem is the query plan for the sub-query. It can choose between an index headed by col3 and another on col4. So I create a test_case.sql with:

unload to /dev/null select c.col1
from ibm_test_case c
where
        c.col3 = 123456789 and
        c.col4 = 1234567 and
        c.col13 = ( select max ( c2.col13 ) from ibm_test_case c2
                where
                        c2.col3 = c.col3 and
                        c2.col4 = c.col4
                );

-- QUERY
unload to /dev/null select c.col1
from ibm_test_case c
where
        c.col3 = 123456789 and
        c.col4 = 1234567 and
        c.col13 = ( select --+ INDEX ( c2 ix_col3_col13 )
                max ( c2.col13 ) from ibm_test_case c2
                where
                        c2.col3 = c.col3 and
                        c2.col4 = c.col4
                );

Note that on the second query I'm forcing the use of a particular index.
Then we run:

ixprofiling stores test_case.sql

and we get the following output:

Database selected.

Engine statistics RESETed. Query results:

Explain set.


1 row(s) unloaded.


Thread profiles (SID: 2690)
LkReq LkWai DLks  TOuts LgRec IsRd  IsWrt IsRWr IsDel BfRd  BfWrt LgUse LgMax SeqSc Srts  DskSr SrtMx Sched CPU Time    Name        
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----------- ------------ 
5224  0     0     0     0     2611  0     0     0     2646  0     0     0     0     0     0     0     2170  0.051671256 sqlexec     

Partitions profiles (Database: stores)
LkReq LkWai DLks  TOuts DskRd DskWr IsRd  IsWrt IsRWr IsDel BfRd  BfWrt SeqSc Object name                                           
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ------------------------------------------------------
6     0     0     0     0     0     2     0     0     0     10    0     0     systables
2609  0     0     0     1933  0     2607  0     0     0     2609  0     0     ibm_test_case
1     0     0     0     2     0     1     0     0     0     6     0     0     ibm_test_case#ix_col3_col13
2608  0     0     0     3     0     1     0     0     0     21    0     0     ibm_test_case#ix_col4
Engine statistics RESETed. Query results:

1 row(s) unloaded.


Thread profiles (SID: 2690)
LkReq LkWai DLks  TOuts LgRec IsRd  IsWrt IsRWr IsDel BfRd  BfWrt LgUse LgMax SeqSc Srts  DskSr SrtMx Sched CPU Time    Name        
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----------- ------------ 
17    0     0     0     0     6     0     0     0     31    0     0     0     0     0     0     0     188   0.003161049 sqlexec     

Partitions profiles (Database: stores)
LkReq LkWai DLks  TOuts DskRd DskWr IsRd  IsWrt IsRWr IsDel BfRd  BfWrt SeqSc Object name                                           
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ------------------------------------------------------
6     0     0     0     0     0     2     0     0     0     10    0     0     systables
4     0     0     0     2     0     1     0     0     0     4     0     0     ibm_test_case
7     0     0     0     0     0     6     0     0     0     17    0     0     ibm_test_case#ix_col3_col13

So, we can now analyze the differences. As you can see the output is more friendly than the output from onstat. On the session section we can see the usual counters, plus the number of times the engine scheduled the thread(s) to run, the CPU time consumed and the name of the threads.
On the tables/partitions section, we can find the partition, table or index name in a friendly nomenclature (instead of the partnum).
As for the comparison, you can spot a big difference. Much more buffer reads and ISAM reads for the first query plan and also a bigger CPU time. Be aware however that for very fast queries the CPU times may show very big variance so don't assume a lower CPU time is always associated with the better query plan. You should repeat the test many times to see the oscillations.
Also note that the meaning of ISAM calls is many times misunderstood. Some people think it's the number of "SELECTs", others the number of rows returned... In reality it's the number of internal functions calls. Some engine settings like BATCHEDREAD_TABLE and BATCHEDREAD_INDEX may influence the number of calls for the same query and query result.

That's all for now. I leave you with the repository and hopefully future articles will focus on some of these scripts. Feel free to use them and send me you suggestions.

Versão Portuguesa:

A necessidade...

O fina do ano é tipicamente uma altura critica para os informáticos. Continuando no mesmo tema do último artigo, continuo a trabalhar com problemas de performance. "Problemas de performance em Informix?!" poderão estar a pensar... Bem, sim, mas para vos dar uma ideia do sistema sobre o qual estou a falar, posso dizer que recentemente notámos três pequenas tabelas (entre 3 e 60 linhas) que entre a meia-noite e as onze da manhã eram varridas (sequential scan) 33M de vezes. Para poupar nas contas posso já dizer que dá cerca de 833 scans/queries por segundo para cada uma das tabelas. E isto começou a acontecer recentemente sobre a carga "normal" que perto de 3000 sessões podem criar.
Portanto, a ideia é que cada bocadinho de performance tem impacto. Na maioria dos casos, este sistema não tem queries longas. Na maior parte das vezes os problemas são pedidos com curta duração mas feitos um imenso número de vezes. E sim, isto torna a vida dos DBAs mais dicfícil... Se tivermos queries longas com maus planos de execução são normalmente fáceis de identificar. Mas se tivermos um grande número de queries muito curtas, com um plano de execução questionável, isso é muito mais difícil de encontrar.

Ainda recentemente tive uma dessas situações. Detectei uma query com um plano de execução duvidoso. O plano de execução varia com os parâmetros usados e ambas as alternativas têm um tempo de resposta "imediato" (fracção de segundo). Não foi a primeira vez que encontrei algo semelhante, e na maioria dos casos em que enfrento uma situação duas vezes, normalmente decido que preciso de alguma ferramenta que me ajude no futuro.

A ideia!

O objectivo era evidenciar a diferença no trabalho feito pelo motor entre dois planos de execução. E quando refiro "ferramenta" estou a pensar num script. A última vez que me lembro de ter tido uma situação destas usei um truque no dbaccess para obter os indicadores de performance tanto para a sessão como para as tabelas envolvidas.
Alguns de vós saberão, outros não, mas quando o dbaccess lê um scritpt SQL pode reconhecer uma linha começada com "!" como uma instrução para executar o resto da linha como um comando SHELL. Assim, o que fiz em situações anteriores foi alterar o script SQL que continha a query para algo do género:

!onstat -z

SELECT .... FROM .... WHERE ...

!um_shell_scritpt

onde um_shell_script tem a capacidade de encontrar a sessão e correr um onstat -g tpf e também um onstat -g ppf. Ests dois comandos mostram-nos uma série de contadores de performance respectivamente da sessão/thread (tpf) e das partições (ppf). O output é semelhante a isto:

IBM Informix Dynamic Server Version 11.70.UC4 -- On-Line -- Up 7 days 23:42:15 -- 411500 Kbytes

Thread profiles
tid lkreqs lkw dl to lgrs isrd iswr isrw isdl isct isrb lx bfr bfw lsus lsmx seq
24  0      0   0  0  0    0    0    0    0    0    0    0  0   0   0    0    0  
26  0      0   0  0  0    0    0    0    0    0    0    0  95  95  0    0    0  
51  32917  0   0  0  21101 13060 3512 57   532  3795 0    0  91215 29964 0    125008 4226
52  39036  0   0  0  9099 11356 2648 80   1372 265  0    0  45549 9312 0    244900 21 
49  705    0   0  0  574  8938 0    139  0    139  0    0  22252 148 0    5656 541
2444 706    0   0  0  14   344  0    4    0    0    3    0  819 7   136  224  0

É-nos mostrado o ID da thread, número de pedidos de lock, esperas em locks, deadlocks, lock timeouts, chamadas ISAM (leitura, escrita, re-escrita, apagar, commit e rollback), transacções longas, leituras e escritas de buffers, espaço usado em logical logs e máximo espaço usado em logical logs e número de sequential scans. E isto:

panther@pacman.onlinedomus.com:informix-> onstat -g ppf | grep -v "0     0     0     0     0     0     0     0     0     0     0     0"

IBM Informix Dynamic Server Version 11.70.UC4 -- On-Line -- Up 7 days 23:43:41 -- 411500 Kbytes

Partition profiles
partnum    lkrqs lkwts dlks  touts isrd  iswrt isrwt isdel bfrd  bfwrt seqsc rhitratio
0x100001   0     0     0     0     0     0     0     0     13697 0     0     100
0x100002   993   0     0     0     445   0     0     0     1460  0     2     100
0x10002d   6769  0     0     0     2379  34    340   34    9094  581   2     100
0x10002e   164   0     0     0     166   0     0     0     472   0     2     100
0x10002f   2122  0     0     0     2750  0     0     0     5288  0     0     100
0x100030   0     0     0     0     4     0     0     0     700   0     4     100
0x100034   14192 0     0     0     5922  192   80    192   15566 1274  0     100
0x100035   2260  0     0     0     188   80    0     80    2766  655   4     100
0x100036   1350  0     0     0     548   34    0     34    1872  249   0     100
0x100037   80    0     0     0     16    4     0     4     346   28    0     100
0x100038   4720  0     0     0     738   360   0     360   3734  1557  0     100

que nos mostra alguns dos contadores anteriores, mas por partição.
Note-se que re-inicializo os contadores, corro a query e depois obtenho os outputs. Idealmente não deverá estar mais nada a correr na instância (é preferível usar uma instância de teste).

Partilha

Mas decidi tornar isto um pouco mais fácil e criei um script para o fazer. Estou também a usar este artigo para anunciar que a partir de hoje, tentarei manter a minha colecção de scripts disponível num site público:

http://onlinedomus.com/informix/viewvc.cgi

Este repositório contém uma quantidade razoável de scripts e outras ferramentas úteis para várias tareafas. Idealmente eu deveria criar documentação e casos de uso para cada um deles, mas de momento isso não está feito. É possível que vá descrevendo alguns destes scripts em futuros artigos, mas sempre integrados em assuntos mais vastos (como este)

Estes scripts foram criados por mim (com uma excepção - setinfx foi criado por Eric Vercelletto quando éramos colegas na Informix Portugal e devemos agradecer-lhe por permitir a distribuição), durante os meus tempos livres e devem conter informação de licenciamento (GPL 2.0). Isto quer dizer que podem ser usados, distribuidos, alterados etc.). Alguns podem não ter esta informação por serem muito antigos.
Naturalmente algumas correcções e melhorias foram feitas durante projectos em clientes, sempre que detecto algum erro ou hipótese de melhoria no seu uso. Muitos deles foram baseados em ideias que obtive de scripts existents no repositório do IIUG, ou de ideias, problemas e sugestões de colegas (agradecimento especial ao António Lima e ao Adelino Silva)

É importante avisar que os scripts são disponiblizados "como são", sem qualquer tipo de garantia implicita ou explicita e eu não posso ser responsabilizado por qualquer problema que advenha do seu uso. Posto isto, convém também dizer que a maioria dos scripts têm sido usados por mim em clientes ao longo de anos, sem problemas.

Quaisquer comentários e/ou sugestões são bem vindas, e se os achar interessantes terei todo o prazer em os incorportar em futuras versões (desde que não fujam à lógica e utilização do script)
Muitos destes scripts disponibilizam duas opções que fornecem ajuda básica (-h) e informação sobre a versão (-V).
Se utilizar algum destes scripts no seu ambiente, sugiro que verifique periodicamente se houve correcções ou melhorias, consultando o site com alguma regularidade. Sempre que possível evito que novas funcionalidades alterem o comportamento do script.

De volta ao problema

Este artigo foca a análise e comparação dos efeitos de executar uma query com dois (ou mais) planos de execução. O script criado para isso chama-se ixprofiling. Se corrido com a opção -h (help) mostra-nos:

panther@pacman.onlinedomus.com:fnunes-> ./ixprofiling -h
ixprofiling [ -h | -V ]
            -s SID database
            [-z|-Z|-n] database sql_script
     -h             : Get this help
     -V             : Get script version
     -s SID database: Get stats for session (SID) and database
     -n             : Do NOT reset engine stats
     -z             : Reset engine stats using onstat (default - needs local database)
     -Z             : Reset engine stats using SQL Admin API (can work remotely )

Vejamos o que fazem as opções:

-s SID base_dados
Mostra informação semelhante ao onstat -g tpf (para a sessão indicada por SID) e onstat -g ppf (para a base de dados indicada)
Irá mostrar informação para todas as partições na base de dados escolhida, para as quais exista pelo menos um dos contadores com valor diferente de zero. Note-se que quando refiro partição estou a referir-me a uma tabela, a um fragmento de tabela fragmentada (ou se preferir particionada) ou a um indíce.
base_dados script_sql
Corre o script SQL indicado, fazendo alterações que irão (por omissão), re-inicializar os contadores de performance do motor (opção -z). Veja mais informação sobre o script SQL abaixo
-n
Evita a re-inicialização dos contadores de performance (se não fôr administrador do sistema de base de dados terá de usar esta opção para evitar erros)
-z
Faz a re-inicialização dos contadores do motor usando o comando onstat -z. Esta é a forma mais simples e rápida de o fazer, mas requer que a base de dados seja local
-Z
Faz a re-inicialização dos contadores utilizando a SQL Admin API, de forma que possa ser feito com bases de dados remotas

E agora vejamos um exemplo de uso. O script tem algumas particularidades que merecem ser datalhadas.
Primeiro e porque a ideia é comparar dois ou mais planos de execução, podemos colocar todas as variantes de plano de execução dentro do mesmo script SQL usando uma linha como esta para separar as queries:

-- QUERY

Estas linhas são automaticamente substituídas por comandos que obtêm os contadores actuais (da query anterior) e que re-inicializam os mesmos contadores preparando a execução seguinte. Se usar apenas uma query não é necessário isto, pois por omissão a re-inicialização dos contadores é feita no início, e após a última query são automaticamente mostrados os contadores.
Se colocar duas ou mais queries no script não se esqueça de terminar cada uma com ";" ou o script não funcionará como esperado.
Vamos ver um exemplo prático. Tenho uma tabela com a seguinte estrutura:

create table ibm_test_case 
  (
    col1 integer,
    col2 smallint not null ,
    col3 integer,
    col4 integer,
[... parte irrelevante ... ]
    col13 datetime year to second,
[... mais colunas irrelevantes ... ]
  );

create index ix_col3_col13 on ibm_test_case (col3,col13) using btree ;
create index ix_col4 on ibm_test_case (col4) using btree ;

e uma query com:

select c.col1
from ibm_test_case c
where
        c.col3 = 123456789 and
        c.col4 = 1234567 and
        c.col13 = ( select max ( c2.col13 ) from ibm_test_case c2
                where
                        c2.col3 = c.col3 and
                        c2.col4 = c.col4
                );

O problem é o plano de execução da sub-query. Pode escolher entre um índice começado pela coluna col3 e outro pela coluna col4. Por isso crio um ficheiro, caso_teste.sql com:

unload to /dev/null select c.col1
from ibm_test_case c
where
        c.col3 = 123456789 and
        c.col4 = 1234567 and
        c.col13 = ( select max ( c2.col13 ) from ibm_test_case c2
                where
                        c2.col3 = c.col3 and
                        c2.col4 = c.col4
                );

-- QUERY
unload to /dev/null select c.col1
from ibm_test_case c
where
        c.col3 = 123456789 and
        c.col4 = 1234567 and
        c.col13 = ( select --+ INDEX ( c2 ix_col3_col13 )
                max ( c2.col13 ) from ibm_test_case c2
                where
                        c2.col3 = c.col3 and
                        c2.col4 = c.col4
                );

Repare que na segunda query estou a forçar o uso de um determinado índice:
Depois corro:

ixprofiling stores caso_teste.sql

e obtemos o seguinte:

Database selected.

Engine statistics RESETed. Query results:

Explain set.


1 row(s) unloaded.


Thread profiles (SID: 2690)
LkReq LkWai DLks  TOuts LgRec IsRd  IsWrt IsRWr IsDel BfRd  BfWrt LgUse LgMax SeqSc Srts  DskSr SrtMx Sched CPU Time    Name        
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----------- ------------ 
5224  0     0     0     0     2611  0     0     0     2646  0     0     0     0     0     0     0     2170  0.051671256 sqlexec     

Partitions profiles (Database: stores)
LkReq LkWai DLks  TOuts DskRd DskWr IsRd  IsWrt IsRWr IsDel BfRd  BfWrt SeqSc Object name                                           
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ------------------------------------------------------
6     0     0     0     0     0     2     0     0     0     10    0     0     systables
2609  0     0     0     1933  0     2607  0     0     0     2609  0     0     ibm_test_case
1     0     0     0     2     0     1     0     0     0     6     0     0     ibm_test_case#ix_col3_col13
2608  0     0     0     3     0     1     0     0     0     21    0     0     ibm_test_case#ix_col4
Engine statistics RESETed. Query results:

1 row(s) unloaded.


Thread profiles (SID: 2690)
LkReq LkWai DLks  TOuts LgRec IsRd  IsWrt IsRWr IsDel BfRd  BfWrt LgUse LgMax SeqSc Srts  DskSr SrtMx Sched CPU Time    Name        
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----------- ------------ 
17    0     0     0     0     6     0     0     0     31    0     0     0     0     0     0     0     188   0.003161049 sqlexec     

Partitions profiles (Database: stores)
LkReq LkWai DLks  TOuts DskRd DskWr IsRd  IsWrt IsRWr IsDel BfRd  BfWrt SeqSc Object name                                           
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ------------------------------------------------------
6     0     0     0     0     0     2     0     0     0     10    0     0     systables
4     0     0     0     2     0     1     0     0     0     4     0     0     ibm_test_case
7     0     0     0     0     0     6     0     0     0     17    0     0     ibm_test_case#ix_col3_col13

Então, podemos agora analisar as diferenças. Como se pode ver o resultado é mais simpático que o do onstat. Na secção relativa à sessão, podemos ver os contadores habituais, mais o número de vezes que o motor escalonou a thread para correr, e o tempo de CPU consumido, bem como o nome das threads
Na secção destinada às partições podemos encontrar os nomes das tabelas, partições ou indíces numa nomenclatura fácil de entender (em vez do partnum).
Sobre a comparação, podemos ver uma grande diferença. Muitos mais leituras de buffers e chamadas ISAM para o primeiro plano de execução e também mais consumo de CPU. Mas atenção que para queries muito rápidas os tempos de CPU podem apresentar uma variação muito grande. Por isso convém não assumir imediatamente que um plano de execução é melhor porque se vê um tempo de CPU menor na primeira interação. Deve repetir-se o teste muitas vezes para se verificar as oscilações.
Chamo também a atenção para o significado das chamadas ISAM. Muitas vezes vejo confusões sobre este tema. Algumas pessoas pensam que são o número de SELECTs (para os ISAM reads), ou que serão o número de linhas retornadas... Na realidade é o número de chamadas a funções internas. Algumas configurações do motor como BATCHEDREAD_TABLE e BATCHEDREAD_INDEX podem influenciar o número destas chamadas, para a mesma query e mesmo conjunto de resultados.

É tudo por agora. Deixo-lhe o repositório e a esperança que artigos futuros se foquem em alguns destes scripts. Use-os à vontade e envie quaisquer sugestões.

Optimizer secrets / segredos do optimizador

2011-12-10T15:02:00.001Z

This article is written in English and Portuguese

Este artigo está escrito em Inglês e Português

English version:

Spending a lot of time with customers is great. It gives me time to go beyond the strict task execution that short projects allow. We actually have time to dive deep into what sometimes looks only as a curiosity. I'll describe one of this situations in this post. It started out as a normal performance issue. A query involving a join was causing an hash join and apparently there was an index that could be used. Some quick investigation showed that the datatypes didn't match on the join columns, and as such the index was not being used.
The situation was fixed (using an explicit cast since changing the datatypes would require more deep analysis) and the programmer(s) received an explanation about the issue so that future situations would be avoided. Simple right? Yes... But when you have inquiring minds and programmers with a few minutes to spare you may be surprised. And this was the case. A few weeks later the DBA team received a request to explain why we recommended that the columns used in joins should have the same datatype. A programmer had produced a testcase where the engine was able to convert the parameter sent and use the index. In other words, if the engine is smart enough why should we care?!

Although this could be considered a waste of time (using the same datatypes or explicit cast is a good practice, right?!) the question was interesting enough to make us spend some time with it. In fact I had seen situations in the past where apparently sometimes the engine was smart, and others not. I never thought too much about it, since I always recommended to follow the best practices (which clearly saves us some troubles). So, personally I also had this doubt, and together with the customer DBAs we started to do some tests. We came up with a very simple test case that we though would show the problem:

DATABASE stores;

DROP TABLE IF EXISTS tst_int;
DROP TABLE IF EXISTS tst_char;

CREATE TABLE tst_int
(
    c1 INTEGER,
    c2 INTEGER
);
CREATE TABLE tst_char
(
    c1 CHAR(15),
    c2 INTEGER
);

INSERT INTO tst_int
SELECT FIRST 2000 pg_pagenum, pg_partnum FROM sysmaster:syspaghdr;

INSERT INTO tst_char
SELECT FIRST 2000 pg_pagenum, pg_partnum FROM sysmaster:syspaghdr;

CREATE INDEX i_tst_int ON tst_int(c1);
CREATE INDEX i_tst_char ON tst_char(c1);

SET EXPLAIN ON;
SELECT "tst_int with char parameter:", * FROM tst_int WHERE c1 = '12345678';
SELECT "tst_char whth int parameter",* FROM tst_char WHERE c1 = 12345678;

--- demonstrates that each index key is being casted
INSERT INTO tst_char VALUES("a1", 12345678);
SELECT * FROM tst_char WHERE c1 = 12345678;

If we take a look at the query plan we see:

QUERY: (OPTIMIZATION TIMESTAMP: 12-10-2011 23:25:19)
------
SELECT "tst_int with char parameter:", * FROM tst_int WHERE c1 = '12345678'

Estimated Cost: 1
Estimated # of Rows Returned: 1

  1) informix.tst_int: INDEX PATH

    (1) Index Name: informix.i_tst_int
        Index Keys: c1   (Serial, fragments: ALL)
        Lower Index Filter: informix.tst_int.c1 = 12345678

So here the engine was "smart". Meaning it converted the CHAR to an INTEGER and that allowed it to use the index. Nice.

But here:

QUERY: (OPTIMIZATION TIMESTAMP: 12-10-2011 23:25:19)
------
SELECT "tst_char whth int parameter",* FROM tst_char WHERE c1 = 12345678

Estimated Cost: 84
Estimated # of Rows Returned: 1

  1) informix.tst_char: SEQUENTIAL SCAN

        Filters: informix.tst_char.c1 = 12345678

It looks as it's not that smart... Instead of converting the INTEGER parameter to a CHAR and use the index it decides to do the opposite: Converts all the CHARs in that column into INTEGERs and makes a SEQUENTIAL SCAN.
Since I didn't have a good explanation for this we decided to open a PMR to get an official technical support explanation.

Technical support reported that we had something in the documentation that tries to explain this:

http://publib.boulder.ibm.com/infocenter/idshelp/v117/topic/com.ibm.sqls.doc/ids_sqs_1620.htm

This documentation is highly confusing but it tells us something important: If we use a numeric filter against a CHAR column, the database server will convert all the CHAR values to numbers. This is precisely what we saw in the example above. But it still does not explain why. Let me show why with a few examples:

If we have "00123" in the table and we give 123 as the parameter, if we convert the number to CHAR and try to match it, ir would fail. Bad results...
If we have "234" in the column and we give 9 as the parameter for a "less or equal" (col <= 9), if we convert the number to CHAR, and apply the filter to the CHAR type, it would match ("9" >= "234"). Again it would return an incorrect result because by using an INTEGER as a parameter we're assuming INTEGER comparison

So, after this, the rule would seem pretty simple. Something like: "If you use a numeric parameter against a CHAR column, all the values in the column will be converted to numeric. On the other hand, using a CHAR parameter against a numeric column allows the engine to convert the numeric to CHAR and if there is an index on the column it can be used".

But life's not that simple... If it was so simple why couldn't we find it in the documentation? I tried to search for other RDBMS (Oracle and MS SQL) documentation, and in those cases they're very clear about the issue. Something like "whenever an implicit CAST is needed we follow a precedence table of datatypes. The datatype with lower precedence will be converted into the datatype with higher precedence". Sincerely I thought this was a good way to put it, and if we did the same, why not document it properly? So the PMR already opened started to look like a documentation bug.
But again, life sometimes is not simple... And while this was being analyzed and discussed, the customer team discovered an interesting scenario: If you give an integer value as a filter against a CHAR column, AND the length of the integer value (excluding any leading zeros) is equal to the size of the column, than Informix will convert the number to CHAR and eventually will use an index on the specified column.
This is the optimizer being smart. If you think about it, if the number has the same number of digits as the length of the CHAR column, you can convert the number to CHAR and compare it. The result set will be correct no matter the values in question or the operator.

To end the story, while browsing the documentation in search for other topics we came across this:

http://publib.boulder.ibm.com/infocenter/idshelp/v117/topic/com.ibm.perf.doc/ids_prf_536.htm

It's clear and well explained. Informix makes the necessary casts but that can have a real impact on the performance, specially if exists an index on the column. And the optimizer is smart enough to use a better query plan in the only situation where it can be done. Really nice and at least here (Performance Guide) it's well explained. I really don't mind when a PMR generates a bug because that's a product improvement, but I must admit I prefer to be proven wrong and see that the product really works well!

Versão Portuguesa:

É ótimo passar muito tempo com clientes. Dá-me tempo para ir para além da estrita execução de tarefas que os projetos curtos permitem. Temos tempo para aprofundar o que por vezes não parece ser mais que uma curiosidade. Nesta entrada vou descrever uma dessas situações. Começou como um banal problema de performance. Uma query que envolvia um join estava a gerar um hash join havendo um índice que aparentemente podia ser usado. Após uma rápida investigação percebeu-se que os tipos de dados das colunas envolvidas no join não eram iguais e por isso o índice não era usado.
A situação foi corrigida (usando um CAST explícito pois mudar os tipos de dados teria necessitado de uma análise mais profunda e poderia ter outras implicações) e o programador(es) recebeu uma explicação sobre o problema para que situações semelhantes fossem evitadas no futuro. Simples, certo? Sim... Mas quando temos mentes curiosas e programadores com alguns minutos para dispensar podemos ser surpreendidos. E este foi um desses casos. Umas semanas mais tarde a equipa de DBAs do cliente recebeu um pedido para explicar o porquê da recomendação, acompanhado de um caso de teste que demonstrava que o motor conseguia usar um índice mesmo quando os tipos de dados não batiam certo. Por outras palavras, se o motor tem inteligência para o fazer, porque nos devemos nós preocupar?!

Apesar de isto poder ser considerado uma perda de tempo (usar os mesmos tipos de dados ou um CAST explícito é uma boa prática, não é?!) a questão era suficientemente interessante para nos fazer gastar algum tempo com ela. Na realidade já tinha tido situações no passado onde aparentemente o motor parecia inteligente, e outras onde tal não acontecia. Nunca pensei muito no assunto, dado que recomendo sempre que seja seguida as boas práticas (que claramente nos evitam problemas). Portanto, pessoalmente também tinha esta dúvida e em conjunto com os DBAs do cliente iniciámos alguns testes. Criámos um exemplo muito simples que pensamos que demonstra o problema:

DATABASE stores;

DROP TABLE IF EXISTS tst_int;
DROP TABLE IF EXISTS tst_char;

CREATE TABLE tst_int
(
    c1 INTEGER,
    c2 INTEGER
);
CREATE TABLE tst_char
(
    c1 CHAR(15),
    c2 INTEGER
);

INSERT INTO tst_int
SELECT FIRST 2000 pg_pagenum, pg_partnum FROM sysmaster:syspaghdr;

INSERT INTO tst_char
SELECT FIRST 2000 pg_pagenum, pg_partnum FROM sysmaster:syspaghdr;

CREATE INDEX i_tst_int ON tst_int(c1);
CREATE INDEX i_tst_char ON tst_char(c1);

SET EXPLAIN ON;
SELECT "tst_int with char parameter:", * FROM tst_int WHERE c1 = '12345678';
SELECT "tst_char whth int parameter",* FROM tst_char WHERE c1 = 12345678;

--- demonstrates that each index key is being casted
INSERT INTO tst_char VALUES("a1", 12345678);
SELECT * FROM tst_char WHERE c1 = 12345678;

Se olharmos para o plano de execução vemos:

QUERY: (OPTIMIZATION TIMESTAMP: 12-10-2011 23:25:19)
------
SELECT "tst_int with char parameter:", * FROM tst_int WHERE c1 = '12345678'

Estimated Cost: 1
Estimated # of Rows Returned: 1

  1) informix.tst_int: INDEX PATH

    (1) Index Name: informix.i_tst_int
        Index Keys: c1   (Serial, fragments: ALL)
        Lower Index Filter: informix.tst_int.c1 = 12345678

Ou seja, aqui o motor era "esperto". Convertia o CHAR para INTEGER e isso permitia usar o índice. Boa.

Mas aqui:

QUERY: (OPTIMIZATION TIMESTAMP: 12-10-2011 23:25:19)
------
SELECT "tst_char whth int parameter",* FROM tst_char WHERE c1 = 12345678

Estimated Cost: 84
Estimated # of Rows Returned: 1

  1) informix.tst_char: SEQUENTIAL SCAN

        Filters: informix.tst_char.c1 = 12345678

Parece que não é assim tão esperto.... Em vez de converter o parâmetro INTEGER para um CHAR e usar o índice, decide fazer o oposto: Converte todos os CHARs daquela coluna para INTEGERs e executa um SEQUENTIAL SCAN.
Como não tinha uma boa explicação para isto decidi abrir um PMR para obter uma explicação oficial do suporte técnico.

O suporte técnico informou que nós tínhamos algo na documentação que tenta explicar isto:

http://publib.boulder.ibm.com/infocenter/idshelp/v117/topic/com.ibm.sqls.doc/ids_sqs_1620.htm

Esta documentação é altamente confusa, mas diz-nos algo importante: Se usarmos um filtro numérico contra uma coluna do tipo CHAR, o servidor de base de dados irá converter todos os valores CHAR da coluna em números. Isto é exatamente o que encontrámos no exemplo acima. Mas ainda não explica porquê. Deixe-me explicar o porquê com alguns exemplos:

Se tivermos o valor "00123" na tabela e usarmos 123 como parâmetro/filtro, se convertermos o número para CHAR e tentarmos fazer a comparação não vamos retornar nada ('123' != '00123') . Resultados errados...
Se tivermos o valor "234" na coluna e dermos 9 como parâmetro/filtro para uma condição de menor ou igual (col <= 9), se convertermos o número para CHAR isso implicaria que a linha era retornada ("9" >= "234"). Mais uma vez iria retornar um resultado "errado", pois ao usarmos um parâmetro numérico estamos a assumir comparação numérica (onde 9 < 234)

Assim, depois disto a regra parecia muito simples. Algo como "Se usarmos um parâmetro numérico contra uma coluna do tipo CHAR, todos os valores da coluna serão convertidos para numérico. Por outro lado, usar um parâmetro CHAR contra uma coluna numérica permite que o motor converta o parâmetro para número e use um índice caso exista".

Mas a vida não é assim tão simples... Se era assim tão direto porque razão não estava documentado (ou pelo menos nós não tínhamos encontrado)? Tentei procurar na documentação de outros sistemas de gestão de bases de dados (Oracle e MS SQL) , e nestes casos eram bastante claros sobre o assunto. Um resumo livre seria "sempre que um CAST implícito seja necessário, seguimos uma tabela de precedências de tipos de dados. O tipo de dado com menor precedência será convertido para o que tem mais precedência". Sinceramente isto pareceu-me uma forma correta de colocar a questão, e se fazíamos o mesmo porque não ter isto claro na documentaçã? Assim o PMR já aberto parecia encaminhar-se para um bug de documentação.

Mas novamente, a vida por vezes não é simples... E enquanto isto estava a ser analisado e discutido , a equipa do cliente descobriu um cenário interessante: Se usarmos um numero como filtro contra uma coluna do tipo CHAR, e o numero de dígitos desse inteiro (excluindo quaisquer zeros à esquerda) for igual ao número de caracteres definido na coluna, então o número será convertido para CHAR e um eventual índice na coluna será usado.
Isto é o optimizador a ser "esperto". Se pensarmos sobre o assunto, se o número de dígitos do número for igual ao número de caracteres da coluna, podemos convertê-lo para CHAR e compará-lo com a coluna. O resultado será o correto independentemente dos valores em questão e do operador.

Para terminar a história, enquanto consultáva-mos a documentação devido a outro assunto, demos com o seguinte:

http://publib.boulder.ibm.com/infocenter/idshelp/v117/topic/com.ibm.perf.doc/ids_prf_536.htm

Está claro e bem explicado. O Informix efetua os CASTS necessários para resolver queries onde existam inconsistências entre os tipos de dados. Mas isso pode ter um impacto significativo na performance, especialmente se existir um índice na coluna. E o optimizador é suficientemente inteligente para obter um melhor plano de execução na única situação onde isso pode ser feito. Muito correto e pelo menos aqui (Guia de Performance) está bem explicado.
Sinceramente não me importo muito quando um PMR dá origem a um bug, pois isso traduz-se numa melhoria do produto, mas tenho de admitir que prefiro que resulte que estava enganado e ser-me mostrado que o produto está a funcionar bem!

Short notes / Notas curtas

2011-12-10T01:24:00.001Z

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

This is a very short article that consists of a few short notes.
First, as you can notice from the banner above, IIUG is going to organize the 2012 International User Conference in San Diego on April 22-25 2012. Next year's conference will move from the traditional Kansas City location to San Diego, California. As usual, you can get a lot of value for money. I will probably skip this one, but Ill surely miss it. Please consult the conference URL for all the details.

Some time ago I added a blog to my list, mas to be honest at the time I didn't review the content that it already had. Recently, during some investigation I ended up there and I had the opportunity to browse over it's content and it's really interesting. I'm talking about http://www.jfmiii/informix/ . The URL shows that it's author is John Miller, one of the most well known elements of the Informix community. John is the author of a lot of Informix material, specially about update statistics and backup and restore. In the last years is has been involved with Open Admin Tool (OAT). He's also a usual presence in conferences and presentations done or sponsored by IBM. I highly recommend this blog. The blog also includes contributions from other well known members of the community

Still related to blogs, I just added one more to the list: http://informixdba.wordpress.com/ . It's author is Ben Thompson, an UK based Informix and Oralce DBA. Not many articles yet, but it looks promising.

Philip Howard, from Bloor Research talks about the Informix revive and also mentions it in the article "Breakthrough and instrumented applications".

TatukGIS a Polish based GIS software and solution provider recently extended it's products support to Informix and DB2

In a blog hosted by Microsoft, there is a reference to future support for Informix 11 on their BizTalk ESB software in the next release of the product

Versão Portuguesa:

Este é um artigo muito curto e consistirá em algumas notas sobre vários temas.
Primeiro, como pode ver pelo cabeçalho acima, o IIUG vai organizar a conferência internacional de utilizadores de 2012 em San Diego entre 22 e 25 de Abril de 2012. A conferência do ano que vem deixará a localização tradicional em Kansas City e irá para San Diego na California. Como é hábito pode obter bastante valor pelo investimento. Em princípio não irei estar presente, mas irei sem dúvida sentir a falta. Consulte o endereço da conferência para mais detalhes.

Há uns tempos adicionei um blog à lista, mas sinceramente na altura não revi todo o conteúdo que já existia. Recentemente durante alguma investigação que efectuei acabei por lá ir parar e tive oportunidade de verificar que tem conteúdo bastante interessante. Estou a falar de http://www.jfmiii/informix/ . Pelo endereço e conteúdo é fácil perceber que se trata do John Miller um dos mais conhecidos elementos da comunidade Informix. O John tem estado ligado a imenso material sobre Informix, em particular artigos sobre update statistics, backup e restore e outros. Nos últimos anos tem estado por detrás do Open Admin Tool. É também presença habitual em conferências e apresentações da IBM. Recomendo vivamente. O blog contém também contribuições de outros elementos bem conhecidos da comunidade

Ainda relacionado com blogs, acabei de adicionar um à lista: http://informixdba.wordpress.com/ . O seu autor é Ben Thompson, um DBA Informix e Oracle baseado no Reino Unido. Ainda não tem muitos artigos, mas parece promissor.

Philip Howard, da Bloor Research fala sobre o Informix revive e também o refere noutro artigo: "Breakthrough and instrumented applications".

TatukGIS, um fornecedre de software e soluções GIS, baseado na Polónia anunciou recentemente a extensão do suporte nos seus produtos para Informix e DB2

Num blog hospedado na Microsoft, existe uma referencia ao futuro suporte ao Informix 11 na próxima release do seu BizTalk ESB.

Informix 11.70.xC4 is available / Informix 11.70.xC4 está disponível

2011-11-03T00:05:00.001Z

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English Version:

IBM has relesed Informix 11.70.xC4 in October 25. The changes in this release, taken directly from the release notes, are (comments added):

Administration

Enhancements to the OpenAdmin Tool (OAT) for Informix
OAT now allows the management of database users (for non-OS users) and OAT is now delivered and installable with Client SDK for Windows (32bits), Linux (32 and 64 bits) and MAC OS (64 bits)
Enhancements to the Informix Replication Plug-in for OAT
The ER plugin now follows ER improvements and can handle multibyte locales.
Informix Health Advisor Plug-in for OAT
A totally new plugin that can examine a great number of metrics and configuration details, warning you (email) of anything not within the recommended settings and/or defined thresholds.
The checks can be scheduled and you can setup several different profiles. Each will run a specific (and configurable) set of metrics.
Dynamically change additional configuration parameters
Several parameters can now be changed with onmode -wm/-wf. Some of them are really important (WSTATS, AUTO_REPREPARE, CKPTINTVL, DIRECTIVES, OPTCOMPIND, SHMADD) and can save you from planned downtime. Others are more or less irrelevant (some of them could be changed by editing the $ONCONFIG file), but it's important that they can be changed through SQL Admin API for client DBA tools
Compare date and interval values
API extensions to compare datetime and interval values.
Plan responses to high severity event alarms
Could not understand what is new. This could be done before by customizing the ALARMPROGRAM script
Data sampling for update statistics operations
A new parameter (USTLOW_SAMPLE) defines if you want to sample the data for the index information gathering or not (indexes with more than 100.000 leaf pages). 11.70.xC3 did this by default. This can also be set at session level. Note that this can have a dramatic impact on the time it takes to regenerate your statistics. The "LOW" will be the slowest for large tables with indexes...
SQL administration API command arguments for creating sbspaces
New options to create smart blob spaces with logging and access time recording in SQL admin API
Monitor client program database usage
The client program's full path name is now available in onstat -g ses.
Note that although you can use this to monitor and control access, this information is sent by the client side and potentially can be faked (not the average user, but an attacker could do it)
Progress of compression operations
Two new columns in onstat -g dsk show the approximate percentage of the tasks already completed and the estimated time to finish

High availability and Enterprise Replication

Easier setup of faster consistency checking
When using ifx_replcheck and an index is created on it, the CRCOLS are not necessary
Handle Connection Manager event alarms
Scripts used for processing connection manager alarms now have access to two variables that identify their name (INFORMIXCMNAME) and unit name (INFORMIXCMCONUNITNAME). This facilitates the script creation
Easier startup of Connection Manager
When the variable CMCONFIG is set and points to the connection manager configuration file, it can be started, stop and restarted without specifying the configuration file. Much like ONCONFIG is used for the engine
Prevent failover if the primary server is active
A new parameter called SDS_LOGCHECK can specify an number of seconds while the SDS secondaries will monitor the logical logs for activity (which would be generated by the primary server). This tries to implement a safety measure to prevent an SDS server to become a primary after a "false" failure of the primary. Note that usually this is prevented by using I/O fencing, but if that is not available this can be another way to make sure you don't end up with two primaries
Configure secure connections for replication servers
A new parameter called S6_USE_REMOTE_SERVER_CFG defines if the file specified by REMOTE_SERVER_CFG will also be used for client connections using the s=6 SQLHOSTS options (for replication). If this parameter is set to 1 the file will be used, otherwise it will default to the old behavior and use $INFORMIXDIR/etc/hosts.equiv

Security

Global Security Kit (GSKit) support
A new parameter (GSKIT_VERSION) can be used to specify the Global Security Kit version you intend to use. Informix 11.70.xC4 ships with version 8, but can use version 7
Use a file to authenticate server connections in a secured network environment
Already mentioned above (S6_USE_REMOTE_SERVER_CFG)

Time Series data

IBM Informix TimeSeries Plug-in for Data Studio
This new plugin allows the interaction with TimeSeries data from Optim Data Studio and Optim Developer Studio
Delete a range of elements and free empty pages from a time series
Delete improvements in TimeSeries data that should free some pages
Aggregate time series data across multiple rows
Improvement in how we can aggregate TimeSeries data.

Besides bringing some new features, this release also fixes some important bugs that appeared in xC3 around the new automatic read ahead configuration. Apart from this I think it's important to notice the following points:

TimeSeries continues to have a great focus on the current enhancements off Informix. This is expectable and desired considering the great news around customer success stories and the recent benchmark.
The new OAT health plugin. I didn't have time yet to really explore it, but for sure I would have done a few things differently like re-using the alarmprogram configuration to send alarms. But this is great and being a plugin it can easily be changed if it doesn't fit your needs.
The inclusion of OAT inside CSDK is a good step (from my point of view). It makes it easier to get and install. I've installed it very quickly in Windows
The new dynamically changeable parameters are a very good step. Of course I would love to be able to change all the parameters without stopping the instance. But we're getting closer. My next favorites would be (and why):

LOGBUFF, PHYSBUFF
After instance healthchecks, may times these should be changed
I suppose this should not be to hard, since there are a set of each and they're used in a circular fashion. So on change, they could be resized.
LOGBUFF would probably be harder due to it's role in replication (HDR)
TBLSPACE_STATS
Again, it's a good practice to have this active. But having to stop the instance to fix this is not nice
SYSSBSPACENAME, SBSPACENAME
Sometimes these are not set, but the usage of some new features required them. A restart is not nice...
CLEANERS
Again, many times needed after a configuration check
SHMTOTAL
Many customers don't set it. And sometimes you may need to reduce it or increase it (new OS are able to add/remove memory online). Of course we would not be able to lower it below current usage.
DD_*, DS_*, PC_*, PLCY_*, USRC_
Again, usual candidates to change after a health check. These would be trickier to change, but if we did it for statement cache we should be able to do it for all the other caches. Also a functionality to "flush" these caches or at least remove some entries would be nice.
EXT_DIRECTIVES
Some times customers find out they need it, but it's off by default... Again the restart
DBCREATE_PERMISSION
This is in my view dynamic by nature

Versão Portuguesa:

A IBM lançou o Informix 11.70.xC4 no dia 25 de Outubro. Estas são as mudanças nesta versão (retiradas directamente das release notes (comentários adicionados):

Administração

Melhorias no OpenAdmin Tool (OAT)
O OAT permite agora a gestão dos utilizadores de base de dados (para utilizadores não autenticados no sistema operativo) e é agora distribuido com o Client SDK para Windows (32bits), Linux (32 and 64 bits) e MAC OS (64 bits)
Melhorias no plugin de replicação do OAT
O plugin de ER segue as emlhorias do próprio ER e pode lidar com locales multibyte
Informix Health Advisor Plug-in para o OAT
Um plugin totalmente novo que pode examinar um grande número de métricas e detalhes de configuração, avisando (por email) de algo que fuja às recomendações e/ou a parâmetros pré-definidos. Podemos calendarizar verificações periódicas de acordo com vários perfis. Cada perfil irá validar um conjunto de métricas especificas (e configurável)
Alteração dinâmica de mais parâmetros
Vários parâmetros podem agora ser mudados com o onmode -wm/-wf. Alguns são realmente importantes (WSTATS, AUTO_REPREPARE, CKPTINTVL, DIRECTIVES, OPTCOMPIND, SHMADD) e podem evitar paragens planeadas. Outros são relativamente irrelevantes (alguns já podiam ser alterados editando o $ONCONFIG), mas é importante que possam ser alterados através da SQL Admin API, para que possam ser mudados em ferramentas cliente
Comparação de datas e intervals
Extensão da API extensions para comparar valores dos tipos datetime e interval
Planear resposta a eventos de alta severidade
Não consegui perceber o que foi feito de novo. Isto já podia ser feito através da configuração/adaptação do script configurado no parâmetros ALARMPROGRAM
Data sampling para operações de UPDATE STATISTICS
Um novo parâmetro (USTLOW_SAMPLE) define se queremos efectuar sampling na recolha de dados sobre os índices ou não (índices com mais de 100.000 "folhas" - leaf pages). 11.70.xC3 fazía-o por omissão. Isto pode ser activado ao nível da sessão. Note-se que isto pode ter um impacto dramático no tempo que leva a refazer as estatísticas. A opção "LOW" é a mais lenta para tabelas grandes em muitos casos..,
Novos argumentos para criar smart blob spaces com a SQL administration API
As novas opções permitem criar os smart blob spaces com ou sem logging e mantendo ou não o tempo de acesso aos objectos
Monitorização do uso das bases de dados por programa cliente
O nome (caminho) completo do programa cliente está disponível no output do onstat -g ses
Note-se que apesar de isto poder ser usado para monitorizar ou até condicionar o acesso a uma base de dados, esta informação é enviada pelo cliente e pode potentcialmente ser alterada (não pelo utilizador comum, mas certamente por um atacante)
Consulta do progresso das operações de compressão
Duas novas colunas no output do onstat -g dsk mostras a percentagem aproximada de trabalho já efectuado e o tempo estimado para a sua conclusão

Alta disponibilidade e Enterprise Replication

Configuração mais fácil de verificação de consistência
Quando se usa o ifx_replcheck, e se cria um índice por ele, os CRCOLS não são necessários
Lidar com alarmística do Connection Manager
Scripts usados para processar os alarmes do(s) connection managers têm agora acesso a duas variáveis que identificam o seu nome (INFORMIXCMNAME) e nome de unidade (INFORMIXCMCONUNITNAME). Isto facilita a criação dos scripts
Arranque facilitado do Connection Manager
Quando a variável CMCONFIG está definida e aponta para o ficheiro de configuração do Connection Manager, este pode ser iniciado, parado e re-iniciado sem especificar o ficheiros de configuração. Muito semelhante à utilização da variável ONCONFIG para o motor
Prevenção de failover se o servidor primário ainda estiver activo
Um novo parâmetro, chamado SDS_LOGCHECK pode indicar o número de segundos que os SDS secundários irão monitorizar os logical logs para detectar actividade (que a existir seria gerada pelo primário). Isto tenta implementar uma medida de segurança para prevenir que um servidor SDS se torne primário em caso de falsa falha do primário. Note-se que habitualmente isto é prevenido com recurso ao I/O fencing, mas se essa funcionalidade não estiver disponível, esta pode ser outra forma de evitar ficar com dois servidores primários
Configuração de segurança para servidores em replicação
Um novo parâmetro, S6_USE_REMOTE_SERVER_CFG define se o ficheiro indicado pelo parâmetro REMOTE_SERVER_CFG será também usado para conexões que utilizem a opção s=6 do SQLHOSTS (para replicação). Se o parâmetros estiver a 1 o referido ficheiro será utilizado, caso contrário o comportamento antigo será o escolhido e o ficheiro a usar será $INFORMIXDIR/etc/hosts.equiv

Segurança

Suporte ao Global Security Kit (GSKit)
Um novo parâmetros, GSKIT_VERSION, pode ser usado para definir a versão do Global Security Kit que se pretende usar. O Informix 11.70.xC4 incluí a versão 8, mas pode trabalhar com a versão 7
Utilizacão de um ficheiro para autenticar conexões de servidores numa rede segura
Já mencionado atrás (S6_USE_REMOTE_SERVER_CFG)

Dados Time Series

IBM Informix TimeSeries Plug-in para Data Studio
Este novo plugin permite interagir com dados TimeSeries a partir do Optim Data Studio e do Optim Developer Studio
Apagar um intervalo de elementos e libertar páginas vazias de um time series
Melhorias nos DELETEs em dados TimeSeries que permitem libertar espaço
Agregar dados time series cruzando várias linhas
Melhorias na forma como podemos agregar informação guardada em TimeSeries

Para além de trazer algumas novas funcionalidades, esta versão também corrige alguns bugs importantes em torno da funcionalidade de read ahead automático introduzido na versão 11.70.xC3. Fora isto, julgo que é importante salientar os seguintes pontos:

O TimeSeries continua a receber muito do foco das últimas melhorias no Informix. Isto é expectável e desejável considerando as boas notícias sobre histórias de sucesso e o recente benchmark
O novo health plugin do OAT. Não tive muito tempo ainda para o explorar, mas certamente faria algumas coisas de forma diferente, como por exemplo re-utilizar a configuração do ALARMPROGRAM para o envio de alarmes. Mas a criação deste plugin é uma óptima ideia e sendo um plugin pode ser alterado facilmente para se ajustar às nossas necessidades
A inclusão do OAT dentro do Client SDK é um bom passo (do meu ponto de vista). Torna ainda mais fácil obter e instalar o OAT. Já o instalei em Windows aproveitando o upgrade de versão que fiz ao Client SDK
A possibilidade de mudar dinamicamente mais parâmetros é excelente. Naturalmente que gostaria que todos os parâmetros da instância tivessem esta capacidade. Mas estamos cada vez mais perto. Os meus próximos favoritos seriam (e porquê):

LOGBUFF, PHYSBUFF
Depois de uma análise a uma instância, muitas vezes estes devem ser mudados.
Imagino que torná-los dinâmicos não fosse muito difícil, pois existem vários buffers que são usados de forma circular. Assim, após um pedido de mudança, quando passa de um para outro podia aproveitar-se para fazer a alteração. O LOGBUFF seria mais difícil pela importância que tem na replicação (HDR)
TBLSPACE_STATS
Também aqui é uma boa práctica ter este parâmetro activo. Mas se for detectado que não está, ter de parar a instância para o mudar não é simpático
SYSSBSPACENAME, SBSPACENAME
Muitas vezes estes não são definidos, mas a decisão de usar novas funcionalidades torna-os necessários. Mais uma vez, obrigar a paragem não é simpático...
CLEANERS
Muitas vezes necessita ser alterado após uma análise à configuração e comportamento da instância
SHMTOTAL
Muitos clientes não o definem. E por vezes podemos ter de reduzir ou aumentar o valor (os novos sistemas operativos já permitem adicionar/remover memória dinamicamente). Naturalmente não seria possível baixar o valor abaixo da quantidade já em uso
DD_*, DS_*, PC_*, PLCY_*, USRC_
Mais candidatos habituais a mudança após uma análise de configuração. Estes seriam possivelmente dos mais complexos de tornar dinâmicos, mas se já se faz para a statement cache deveria ser possível fazer para estes também. Para além disso, uma funcionalidade para limpar uma das caches (ou pelo menos remover alguma entrada) seria útil em determinadas situações
EXT_DIRECTIVES
Alguns clientes descobrem que precisam de o usar, mas está desligado por default. E uma paragem nunca é desejável
DBCREATE_PERMISSION
Este é a meu ver dinâmico por natureza

Spanish Informix user group / Grupo Espanhol de utilizadores Informix

2011-09-13T22:50:00.003+01:00

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

I suppose this article should be written in Spanish but unfortunately I'm too limited for that. I recently noticed the appearance of the Spanish Informix User Group site. Accordingly to the information online it's recent and it will be launched in this Autumn with the presence of several Informix specialists.

If your country is Spain, or your native language is Spanish, and you use Informix (or just want to learn more about it) I think and hope that this will be a new reference. I've seen some signs of interest in Informix in my neighbor country and this is another one.

I wish all the best to the founders and I hope they'll be able to attract the users and serve the community. And for the Portuguese community, this can also be interesting. There's a large number of people here to whom the language will not be a big issue, so maybe we can also enjoy and take advantage of this initiative (even due to the geographic proximity)

Versão Portuguesa:

Suponho que este artigo deveria ser também escrito em Espanhol/Castelhano, mas infelizmente sou demasiado limitado para isso. Notei recentemente o aparecimento do site do Grupo Espanhol de Utilizadores Informix. Segundo a informação lá colocada é recente e será lançado neste Outono com a presença de vários especialistas Informix.

Se o seu país é a Espanha ou se o Espanhol é uma língua que domina, e usa Informix (ou apenas deseje aprender mais sobre ele) penso e espero que isto venha a ser uma nova referência. Tenho visto alguns sinais de interesse no Informix no meu país vizinho e este é mais um.

Desejo as maiores felicidades aos fundadores e espero que consigam atrair os utilizadores e servir a comunidade. Também para a comunidade Portuguesa isto pode ser interessante. Existe por cá muita gente para quem a língua não será um obstáculo e portanto poderão disfrutar e tirar partido desta iniciativa (até pela proximidade geográfica)

Get pending In Place ALTERs / Obter as tabelas com InPlace ALTERs pendentes

2011-09-09T22:44:00.001+01:00

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

Introduction

The topic of in place ALTERed tables has always been present in Informix. We say a table was ALTERed in place when an ALTER TABLE instruction resulted in a new table schema, but the table was not physically changed. This is very helpful on large and busy tables. It means you can do the ALTER TABLE quickly (instantaneously) and with minimum immediate impact on system resources. Internally Informix does a very simple thing from the user point of view, but that can be complex from the engine point of view: A new version of the table definition is created, and from there on, any instruction (DML) affecting the data will use the new version. The table's existing pages are left on the older version but each time we SELECT them, the engine converts the row(s) to the new format. Additionally if we update a row, the page where it is stored will be written in the new format.

For example, if we have a table with lots of data pages, and we add a column, this will do an in place ALTER. Certain types of ALTERs don't allow in place ALTERs. For example, if we change a CHAR(5) column to a SMALLINT, this will be a slow ALTER. This usually happens when the system cannot immediately guarantee that the existing data can be stored in the new representation.

When the engine decides that it can do an in place ALTER, we don't have the option to inhibit it. Meaning the ALTER table will be done as an in place ALTER, and if we want to force the physical changes, we must do what we usually call a dummy UPDATE: UPDATE tabname SET column = column;

Impacts of in place ALTERs

There are several impacts on having tables with in place ALTERs. The immediate one is that your updates will be slightly slower, since the whole page will be converted and written. Note that this does not necessarily means higher I/O load, since the page is the smallest unit written by the engine. In other words, even if your table does not have more than one version of it's definition, when we change a single row of data, a whole page (at least) will be written. But the other rows of the page don't need to be changed. And changing an older version can mean your data will not fit on one page after conversion. So there can be more I/O.
Another potential issue is that like with any other part of the engine, the mechanism of in place ALTER can have issues. This is an overrated aspect, but it's true we've seen problems that only affect tables with in place ALTERs.

But the real issue with in place ALTERs refers to upgrades and downgrades. Through versions there have been great controversy regarding the real impact of doing in-place upgrades (conversions) with tables with pending in-place ALTERs. I've searched through the migration guides for several versions (7.3, 9.2, 9.4, 10, 11.1, 11.5 and 11.7) and they're almost completely consistent: You can upgrade with pending in-place ALTERed tables, but you cannot revert. The only exception I've found was the manual for 9.4 which states that you must remove the pending in-place ALTERs to run the conversion (upgrade) successfully.

The reason for allowing upgrades but not downgrades is pretty simple and acceptable: Informix guarantees that version N+1 can handle all previous situations of in-place ALTERs done in version N or older. But, since each version may have added new situations where in-place ALTERs can be done, we can't risk porting a pending ALTER to an older version that may not be able to handle it. Let me remind you that an in-place ALTER requires the ability to convert from one row version to a newer one (which can have more columns, or different data types etc.)

At the time of this writing I could not verify if the exception in the migration guide of version 9.4 was justified or simply a documentation problem. But the fact is that most people assume they must complete the ALTER tables that were done in-place before converting. By this I mean that they must eliminate all the pages in older versions. A valid reason to do that is that in case you need to revert you don't have to waste time running the dummy updates. Typically, if you have any issue in the new version and need to revert, you'll want to do it as soon as possible. As such, eliminating the pending inplace ALTERs before you upgrade can save you precious time if you really need to revert. In any case, the migration guide for version 11.7 clearly states that you only need to remove the pending inplace ALTERs, if they were caused after the conversion to 11.7. Any previous one (which already exists in the old version) would not need to be eliminated.
As a side note, let me state that the only time I've done reversions was during a customer and partner workshop where we were demoing this functionality... I never had to do it on a real customer situation. In any case the other limitations for reversion can be real challenges, so the pending in-place ALTERs wouldn't be your biggest concern.

Finding in-place alters

Now that we've seen in which situations we should remove pending inplace ALTERs (tables with pages in older versions), we come to another issue that is frequently asked, and to which there are several answers. Most of them are controversial or badly explained which again raises a lot of confusion. The issue is: How do we find tables with pending inplace ALTERs?
There was a discussion in the IIUG forum near the end of 2010 that focused on this issue. As usual, there were three answers to this:

A quick way (based on SQL and SMI that tells us which tables suffered an inplace ALTER, but doesn't show which tables have pending inplace ALTERs. This means that unless you completely rebuild the table, just running dummy UPDATEs will not prevent the table from always appearing in the list generated by this method
A slow way that's based in the oncheck -pT output (this effectively tells you the number of pages in each existing version This method will give you just the tables with pending inplace ALTERs
A technical support tool that searches the tables metadata and can provide the answer pretty quickly. Only problem is that it's not generally available

And this was my motivation to do some research on this issue. After some information exchange with Andreas Legner from IBM technical support in Germany, I was able to create an SQL script that can find the tables with pending inplace alters. The script can give us the details about the number of pages in each version, it returns the database and table name, the version and number of pages it contains.

The great thing about this script is that it's fast (from a few seconds to a few minutes for very large databases) and it really shows you the current status. Contrary to what the option 1) above does, if you do the dummy updates on one table, that table will not show up if you run it again. One warning: If you test this, after the dummy update you need to force a checkpoint. The script goes through the partition headers (because the required info is stored there), and after the dummy updates the partition headers are written to disk only at checkpoint time.

The script comes in the form of a stored procedure and is based only on the sysmaster views. The script was tested with all the versions I could find (7.31, 9.3, 9.4, 10, 11.1, 11.5 and 11.70) and it worked without issues in all of them. So if you're upgrading an old system and want to make sure you clear any pending inplace altered tables this can be a great help.

The SQL containing the script is at the bottom of this article and I will not dig into it with great detail. The challenges I got in developing it were mainly to understand how the needed data was already present in sysmaster views and also on interpreting this data (the representation is different depending on the "endianess" of your platform. Again, for the first one the help from Andreas Legner was precious and for the second one a special thank you goes to Art Kagel. Both of them helped me to review the script and to fix some nasty bugs I had in my first attempts.

Usage

In order to use this procedure, you'll need to copy the script code below, paste it into dbaccess and run it against any of your instance databases. It will create a function called get_pending_ipa() that will return the following fields:

Database
Table name
Partition name
Object type (can be table, partition or partition main)
Partition number
Partition lockid (the partnum of the main partition for fragmented tables)
Table structure version
Number of pages remaining in this version

If you need to create this against a version 7 (pre-V9) you should change the header and footer as commented in the script.
To execute just run

execute function get_pending_ipa();
or
execute procedure get_pending_ipa();

Disclaimer

Although the script was tested as much as I could, please understand that is comes with no guarantee. Use at your one risk. Neither me nor my employer can be considered liable for any harm done by it (difficult to happen since it only SELECTs), or more important for bad decisions taken based on it's output. This is just the usual disclaimer. Naturally I've done my best to make sure it works. If you find any error in the script or if you have any suggestion, feel free to contact me.

Versão Portuguesa:

Introdução

O assunto das tabelas com inplace ALTERs (optei por não traduzir o termo) tem estado sempre presente no Informix. Dizemos que uma tabela tem um inplace ALTER quando uma instrução ALTER TABLE deu origem a uma nova definição (schema) de tabela, mas a mesma não foi fisicamente alterada. Isto é muito útil em tabelas grandes e/ou com muitos acessos. Permite que se faça um ALTER TABLE muito rápido (instantâneo) e com um impacto reduzido no consumo de recursos do sistema. Internamente o Informix faz algo muito simples do ponto de vista do utilizador mas que pode ser bastante complexo se visto pelo ângulo do motor: É criada uma nova definição da estrutura da tabela, e a partir desse momento qualquer instrução (DML) que afecte os dados usará essa nova versão. As páginas já existentes da tabela mantêm-se na versão antiga, mas sempre que façamos um SELECT o motor converte a linha(s) para o novo formato. Adicionalmente, se fizermos um UPDATE a página onde estiver guardado o registo(s) será convertida pelo motor para o novo formato.

Por exemplo, se tivermos uma tabela com muitas páginas de dados, e adicionar-mos uma coluna, isto será feito com um inplace ALTER. Mas alguns tipos de ALTER TABLE não permitem um inplace ALTER. Caso mudemos uma coluna de CHAR(5) para SMALLINT, isto será um slow ALTER. Habitualmente isto acontece se o sistema não puder garantir imediatamente que os dados existentes têm representação ou podem ser guardados no novo tipo de dados (no caso anterior o CHAR(5) pode ter caracteres não numéricos). Se o motor decide que pode fazer um inplace ALTER não temos forma de o inibir. Ou seja, a alteração será forçosamente feita com inplace ALTER e se desejarmos forçar a mudança física temos de fazer o que normalmente se designa de dummy UPDATE: UPDATE tabela SET coluna = coluna;

Impactos dos in place ALTERs

Existem vários impactos em ter tabelas com inplace ALTERs. O mais imediato é que os UPDATEs serão ligeiramente mais lentos, pois toda a página tem de ser convertida e escrita. Note-se que isto não implica maior carga de I/O, pois a página é a unidade de escrita mais pequena do motor. Por outras palavras, mesmo que a sua tabela não tenha mais que uma versão da sua definição, quando mudamos uma linha contida numa página, toda a página (pelo menos) será escrita. Mas as outras linhas da mesma página não são alteradas. E mudar de uma versão anterior da definição para a atual pode implicar que nem todas as linhas caibam na página depois de convertidas. Isso sim, pode implicar mais I/O.
Outro potencial problema é que como em qualquer outra área de código do motor, o mecanismo de inplace ALTER pode ter problemas ou erros. Este aspeto é muitas vezes sobrevalorizado, mas é um facto que já tivemos problemas que só aconteciam em tabelas com inplace ALTERs.

Mas o verdadeiro problema habitualmente associado com os inplace ALTERs diz respeito aos upgrades e downgrades. Através das versões tem existido grande controvérsia relativamente às verdadeiras implicações de se efetuarem conversões (ou upgrades inplace) de versão existindo tabelas com inplace ALTERs pendentes (por pendentes quer-se dizer que têm efetivamente páginas com mais que uma versão de definição ou schema da tabela). Procurei pelos guias de migração de várias versões (7.3, 9.2, 9.4, 10, 11.1, 11.5 e 11.7) e são quase absolutamente consistentes: Pode fazer-se o upgrade com inplace ALTERs pendentes mas não se pode fazer o inverso (regressão). A única exceção a esta regra está no manual da versão 9.4 que refere que os mesmos têm de ser removidos antes de se efectuar a conversão.

A razão para permitir conversões, mas não regredir é bastante simples e compreensível: O Informix garante que a versão N+1 consegue lidar com toas as possibilidades de inplace ALTERs da versão N ou anteriores. Mas dado que em cada versão podem ser adicionadas novas situações onde o motor consegue fazer um inplace ALTER, não podemos correr o risco de portar um inplace ALTER pendente para uma versão anterior que não sabe como lidar com ele. Deixe-me lembrar que um inplace ALTER obriga a que o motor consiga mapear os dados de um formato para outro (com mais colunas, ou tipos de dados diferentes etc.)

No momento da escrita deste artigo não consegui verificar se a exceção no guia de migração da versão 9.4 se pode justificar com um erro de documentação ou se tem outro fundamento. Mas o facto é que a maioria dos utilizadores assumem que têm de completar (ou eliminar) os inplace ALTERs pendentes antes das conversões (upgrades). Uma razão válida para este raciocínio é que caso seja necessário regredir para a versão original não se quererá perder tempo a executar os dummy updates. Ou seja, eliminar os inplace ALTERs pendentes, antes da conversão, pode poupar tempo precioso caso se verifique a necessidade de regredir. O manual da versão 11.7 vai um pouco mais longe e refere que só é necessário remover os inplace ALTERs pendentes, se os mesmos foram gerados já na versão 11.7

Qualquer um anterior (que já existisse na versão original) não necessitará de ser eliminado.
Como um aparte, permita-me que diga que a única vez que fiz regressões foi num workshop para parceiros e clientes com o objetivo de demonstrar a funcionalidade. Nunca tive a necessidade de efectuar isto numa situação real em clientes. Em qualquer caso existem várias limitações às regressões que podem constituir verdadeiros desafios, pelo que os inplace ALTERs não deveriam ser a maior preocupação.

Identificar inplace ALTERs pendentes

Agora que vimos em que situações devemos remover os inplace ALTERs pendentes, chegamos a outro tópico que é alvo frequente de perguntas e discussões. A questão é: Como identificamos as tabelas que possuem páginas de dados com várias versões da sua definição? Há várias respostas e regra geral são controvérsias ou mal explicadas o que levanta enormes confusões. Decorreu uma discussão sobre este tema mais uma vez em finais de 2010. Como é hábito foram dadas três respostas para o problema:

Uma forma rápida (baseada em SQL e tabelas SMI) que nos diz as tabelas que sofreram inplace ALTERs mas não permite saber se ainda estão pendentes (existem ainda páginas de dados com formato antigo). Isto significa que a menos que se refaça completamente a tabela, a mera execução dos dummy UPDATEs não impedirá a tabela de voltar a aparecer na lista gerada por este método.
Uma forma lenta, baseada no resultado do oncheck -pT. Isto efetivamente diz-nos quantas páginas de dados existem para cada formato da tabela. Este método permite realmente identificar os inplace ALTERs pendentes.
Uma ferramenta do suporte técnico que procura na metadata das tabelas e pode fornecer a resposta de forma rápida. O único problema é que não está disponível para os utilizadores em geral

E isto foi a minha motivação para efetuar alguma pesquisa sobre este tema. Após alguma troca de informação com o Andreas Legner do suporte técnico da IBM na Alemanha, consegui criar um script SQL que pode reportar as tabelas com inplace ALTERs pendentes. Este script consegue fornecer o número de páginas existentes em cada versão da definição da tabela. Retorna a base de dados, a tabela, a versão(ões) e quantas páginas contém.

O bom deste script é que é rápido (de uns segundos a poucos minutos para bases de dados muito grandes), e mostra a situação actual. Contrariamente à opção 1) acima, depois de fazermos os dummy UPDATEs numa tabela, essa mesma tabela não volta a aparecer no output do script. Apenas um aviso relativamente a isto: O script percorre o que chamamos de partition headers e estes só são escritos em disco durante um checkpoint. Assim, depois de correr os dummy UPDATEs devem forçar-se um checkpoint (ou esperar que ocorra um) antes de correr novamente o script.

O script traduz-se num procedimento SPL e baseia-se em informação disponível nas views da base de dados sysmaster. O script foi testeado em todas as versões que consegui encontrar (7.31, 9.3, 9.4, 10, 11.1, 11.5 e 11.7) e correru em todas sem problemas. Assim, se estiver a fazer uma conversão de um sistema antigo e quiser limpar todos os inplace ALTERs pendentes nessa instância, isto pode ser uma grande ajuda.

O script SQL contendo o procedimento está disponível no final deste artigo e não vou fazer uma explicação exaustiva do mesmo. Os desafios que enfrentei durante o desenvolvimento do procedimento foram principalmente entender se os os dados necessários estavam representados na base de dados sysmaster e também na interpretação desses dados (a representação dos dados é diferente conforme o "endianess" da plataforma). Mais uma vez, na primeira questão a ajuda do Andreas Legner foi preciosa e para a segunda questão tive a ajuda do Art Kagel a quem enviou um sincero agradecimento. Ambos me ajudaram a rever o procedimento e identificaram alguns bugs feios que tinha nas primeiras tentativas.

Utilização

Para usar esta função terá de copiar o código do script que se encontra no final do artigo, colá-lo num dbaccess (ou outra ferramenta) e executá-lo numa das bases de dados da sua instância. O script irá criar uma função chamada get_pending_ipa() que irá retornar os seguintes valores:

Nome da base de dados
Nome da tabela
Nome da partição
Tipo de objecto (pode ser table, partition ou partition main)
Número da partição
lockid da partição (o número da partição principal para tabelas fragmentadas)
Versão da estrutura da tabela
Número de páginas ainda existentes nesta versão

Se necessitar de criar a função numa versão 7 (pre-V9) deve alterar o cabeçalho e o final da função de acordo com o recomendado/comentado no código
Para executar basta dar a instrução:

execute function get_pending_ipa();
ou
execute procedure get_pending_ipa();

Exclusão de garantia

Apesar de o script ter sido testado tanto quanto pude, por favor assuma que o mesmo não é fornecido com qualquer tipo de garantia. Utilize-o por sua conta e risco. Nem eu nem o meu empregador poderão ser considerados responsáveis por qualquer mal ou prejuízo derivado do seu uso (difícil dado que apenas faz SELECTs), ou mais importante, por más decisões baseadas no seu output. Isto é apenas o normal termo de des-responsabilização. Naturalmente fiz o meu melhor para assegurar que o procedimento funciona bem e retorna resultados corretos. Qualquer problema que identifique no script ou sugestão de melhoria por favor contacte-me.

SQL script:

CREATE FUNCTION get_pending_ipa() RETURNING
        VARCHAR(128) as database, VARCHAR(128) as table, VARCHAR(128) as partition, VARCHAR(9) as obj_type,
        INTEGER as partnum, INTEGER as lockid, SMALLINT as version, INTEGER as npages
-- For version 7.x use this header instead:
--CREATE PROCEDURE get_pending_ipa() RETURNING VARCHAR(128), VARCHAR(128), VARCHAR(128), VARCHAR(9), INTEGER, INTEGER, SMALLINT, INTEGER;
-- Name: $RCSfile: get_pending_ipa.sql,v $
-- CVS file: $Source: /usr/local/cvs/stable/informix/queries/get_pending_ipa.sql,v $
-- CVS id: $Header: /usr/local/cvs/stable/informix/queries/get_pending_ipa.sql,v 1.5 2011/09/09 20:57:31 fnunes Exp $
-- Revision: $Revision: 1.5 $
-- Revised on: $Date: 2011/09/09 20:57:31 $
-- Revised by: $Author: fnunes $
-- Support: Fernando Nunes - domusonline@gmail.com
-- Licence: This script is licensed as GPL ( http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html )
-- Variables holding the database,tabnames and partnum
DEFINE v_dbsname, v_old_dbsname LIKE sysmaster:systabnames.dbsname;
DEFINE v_tabname, v_partname, v_old_tabname LIKE sysmaster:systabnames.tabname;
DEFINE v_partnum, v_old_partnum LIKE sysmaster:syspaghdr.pg_partnum;
DEFINE v_lockid, v_old_lockid LIKE sysmaster:sysptnhdr.lockid;
DEFINE v_pg_next INTEGER;
DEFINE v_pg_partnum INTEGER;
DEFINE v_obj_type VARCHAR(9);
-- Variables holding the various table versions and respective number of pages pending to migrate
DEFINE v_version SMALLINT;
DEFINE v_pages INTEGER;
-- Hexadecimal representation of version and pending number of pages
DEFINE v_char_version CHAR(6);
DEFINE v_char_pages CHAR(10);
DEFINE v_aux_char CHAR(8);
-- Hexadecimal representation of the slot 6 data. Each 16 bytes will appear as a record that needs to be concatenated
DEFINE v_hexdata VARCHAR(128);
-- Variable to hold the sysmaster:syssltdat hexadecimal representation of each 16 bytes of the slot data
DEFINE v_slot_hexdata CHAR(40);
DEFINE v_aux VARCHAR(128);
DEFINE v_endian CHAR(6);
DEFINE v_offset SMALLINT;
DEFINE v_slotoff SMALLINT;
DEFINE v_dummy INTEGER;
-- In case we need to trace the function... Uncomment the following two lines
--SET DEBUG FILE TO "/tmp/get_pending_ipa.dbg";
--TRACE ON;
-- Now lets find out the Endianess ( http://en.wikipedia.org/wiki/Endianness ) of this platform
-- The data in sysmaster:syssltdat will be different because of possible byte swap
-- Read the first slot of the rootdbs TBLSpace tblspace (0x00100001)
-- The first 4 bytes hold the partition number (0x00100001)
SELECT
        s.hexdata[1,8]
INTO
        v_hexdata
FROM
        sysmaster:syssltdat s
WHERE
        s.partnum = '0x100001' AND
        s.pagenum = 1 AND
        s.slotnum = 1 AND
        s.slotoff = 0;
IF v_hexdata = '01001000'
THEN
        -- Byte swap order, so we're little Endian (Intel, Tru64....)
        LET v_endian = 'LITTLE';
ELSE
        IF v_hexdata = '00100001'
        THEN
                -- Just as we write it (no byte swap), so we're big Endian (Sparc, Power, Itanium...)
                LET v_endian = 'BIG';
        ELSE
                -- Just in case something weird (like a bug(!) or physical modification) happened
                RAISE EXCEPTION -746, 0, 'Invalid Endianess calculation... Check procedure code!!!';
        END IF
END IF
-- Flags to mark the beginning
LET v_hexdata = "-";
LET v_old_dbsname = "-";
LET v_old_tabname = "-";
-- The information we want for each version description will occupy this number of characters
-- in the sysmaster:syssltdat.hexdata notation (after removing spaces). The size depends on the engine version.
LET v_offset=DBINFO('version','major');
IF v_offset >= 10
THEN
        LET v_offset = 48;
ELSE
        LET v_offset = 40;
END IF
LET v_old_lockid = -1;
FOREACH
        -- This query will browse through all the instance partitions, excluding sysmaster database, and will look for
        -- any extended partition header (where partition header "next" field is not 0)
        -- the ABS(...) is just a trick to make partnums that are equal to lock id appear at the end
        SELECT
                t.dbsname, t.tabname, t1.tabname, t.partnum, p.pg_partnum, p.pg_next, h.lockid, ABS(h.lockid - h.partnum)
        INTO
                v_dbsname, v_partname ,v_tabname, v_partnum, v_pg_partnum, v_pg_next, v_lockid, v_dummy
        FROM
                sysmaster:systabnames t,
                sysmaster:syspaghdr p,
                sysmaster:sysptnhdr h,
                sysmaster:systabnames t1
        WHERE
                p.pg_partnum = sysmaster:partaddr(sysmaster:partdbsnum(t.partnum),1) AND
                p.pg_pagenum = sysmaster:partpagenum(t.partnum) AND
                t.dbsname NOT IN ('sysmaster') AND
                h.partnum = t.partnum AND
                t1.partnum = h.lockid AND
                p.pg_next != 0
        ORDER BY
                t.dbsname, t.tabname, 8 DESC, t.partnum
        IF v_lockid = v_partnum
        THEN
                IF v_lockid = v_old_lockid
                THEN
                        LET v_obj_type = "Part Main";
                ELSE
                        LET v_obj_type = "Table";
                END IF
        ELSE
                LET v_obj_type = "Part";
        END IF

        LET v_old_lockid = v_lockid;
        WHILE v_pg_next != 0
                -- Find if we're dealing with a fragmented table or not...
                -- While this extended partition page points to another one...
                -- Get all the slot 6 data (where the version metadata is stored - version, number of pages, descriptor page etc.
                FOREACH
                SELECT
                        REPLACE(s.hexdata, ' '), s.slotoff, p.pg_next
                INTO
                        v_slot_hexdata, v_slotoff, v_pg_next
                FROM
                        sysmaster:syspaghdr p,
                        sysmaster:syssltdat s
                WHERE
                        s.partnum = p.pg_partnum AND
                        s.pagenum = p.pg_pagenum AND
                        s.slotnum = 6 AND
                        p.pg_partnum = v_pg_partnum AND
                        p.pg_pagenum = v_pg_next
                IF ( v_dbsname != v_old_dbsname OR v_tabname != v_old_tabname OR v_partnum != v_old_partnum)
                THEN
                        LET v_old_dbsname = v_dbsname;
                        LET v_old_tabname = v_tabname;
                        LET v_old_partnum = v_partnum;
                        -- First iteraction for each table
                        LET v_hexdata = v_slot_hexdata;
                ELSE
                        -- Next iteractions for each table
                        LET v_hexdata = TRIM(v_hexdata) || v_slot_hexdata;
                        IF LENGTH(v_hexdata) >= v_offset
                        THEN
                                -- We already have enough data for a version within a table
                                -- Note that we probably have part of the next version description in v_hexdata
                                -- So we need to copy part of it, and keep the rest for next iteractions
                                LET v_aux=v_hexdata;
                                LET v_hexdata=SUBSTR(v_aux,v_offset+1,LENGTH(v_aux)-v_offset);

                                -- Split the version and number of pending pages part...
                                LET v_char_version = v_aux[1,4];
                                LET v_char_pages = v_aux[9,16];
                                -- Create a usable hex number. Prefix it with '0x' and convert due to little endian if that's the case
                                IF v_endian = "BIG"
                                THEN
                                        LET v_char_version = '0x'||v_char_version;
                                        LET v_char_pages = '0x'||v_char_pages;
                                ELSE
                                        LET v_aux_char = v_char_version;
                                        LET v_char_version[5]=v_aux_char[1];
                                        LET v_char_version[6]=v_aux_char[2];
                                        LET v_char_version[4]=v_aux_char[4];
                                        LET v_char_version[3]=v_aux_char[3];
                                        LET v_char_version[2]='x';
                                        LET v_char_version[1]='0';
                                        LET v_aux_char = v_char_pages;
                                        LET v_char_pages[9]=v_aux_char[1];
                                        LET v_char_pages[10]=v_aux_char[2];
                                        LET v_char_pages[7]=v_aux_char[3];
                                        LET v_char_pages[8]=v_aux_char[4];
                                        LET v_char_pages[6]=v_aux_char[6];
                                        LET v_char_pages[5]=v_aux_char[5];
                                        LET v_char_pages[3]=v_aux_char[7];
                                        LET v_char_pages[4]=v_aux_char[8];
                                        LET v_char_pages[2]='x';
                                        LET v_char_pages[1]='0';
                                END IF
                                -- HEX into DEC (integer)
                                LET v_version = TRUNC(v_char_version + 0);
                                LET v_pages = TRUNC(v_char_pages + 0);
                                IF v_pages > 0
                                THEN
                                        -- This version has pending pages so show it...
                                        RETURN TRIM(v_dbsname), TRIM(v_tabname), TRIM(v_partname), TRIM(v_obj_type), v_partnum, v_lockid, v_version, v_pages WITH RESUME;
                                END IF
                        END IF
                END IF
                END FOREACH
                IF LENGTH(v_hexdata) >= v_offset
                THEN
                        -- If we still have data to process...
                        LET v_aux=v_hexdata;

                        LET v_char_version = v_aux[1,4];
                        LET v_char_pages = v_aux[9,16];
                        IF v_endian = "BIG"
                        THEN
                                LET v_char_version = '0x'||v_char_version;
                                LET v_char_pages = '0x'||v_char_pages;
                        ELSE
                                LET v_aux_char = v_char_version;
                                LET v_char_version[5]=v_aux_char[1];
                                LET v_char_version[6]=v_aux_char[2];
                                LET v_char_version[4]=v_aux_char[4];
                                LET v_char_version[3]=v_aux_char[3];
                                LET v_char_version[2]='x';
                                LET v_char_version[1]='0';
                                LET v_aux_char = v_char_pages;
                                LET v_char_pages[9]=v_aux_char[1];
                                LET v_char_pages[10]=v_aux_char[2];
                                LET v_char_pages[7]=v_aux_char[3];
                                LET v_char_pages[8]=v_aux_char[4];
                                LET v_char_pages[6]=v_aux_char[6];
                                LET v_char_pages[5]=v_aux_char[5];
                                LET v_char_pages[3]=v_aux_char[7];
                                LET v_char_pages[4]=v_aux_char[8];
                                LET v_char_pages[2]='x';
                                LET v_char_pages[1]='0';
                        END IF
                        -- HEX into DEC (integer)
                        LET v_version = TRUNC(v_char_version + 0);
                        LET v_pages = TRUNC(v_char_pages + 0);
                        IF v_pages > 0
                        THEN
                                -- This version has pending pages so show it...
                                RETURN TRIM(v_dbsname), TRIM(v_tabname), TRIM(v_partname), TRIM(v_obj_type), v_partnum, v_lockid, v_version, v_pages WITH RESUME;
                        END IF
                END IF
        END WHILE
END FOREACH;
END FUNCTION;
-- For version 7.x use this close statement instead:
--END PROCEDURE;

10 years of IBM / 10 anos de IBM

2011-08-21T00:25:00.001+01:00

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version

On July 2, 2001, IBM announced the completion of Informix acquisition. So, 10 years have passed since the deal that changed many people lives. A lot was written at the time and since then about the deal, about Informix future, about competitors reactions etc. This historical milestone made me take a look back and think about what's been going on. There are several perspectives about this: The professional, personal, the technical and the marketing ones (and probably more that don't come to mind at this moment). Personally, the acquisition happened three years after I joined Informix Portugal. At the time I was already deeply involved with a Portuguese customer (large Telco) and I believe I gained precious experience since then. Being at IBM I had the opportunity to have some experience with other products (from areas that touch the database area), although the focus was and still is Informix. Informix allowed me to interact with many large (from a small country perspective) companies. So, it was a very positive transition. Of course not everything is perfect. Needless to say that the environment in a small company branch (around 20 people at the time) is by no means similar to the environment of a larger corporation like IBM. The processes inside big corporations are more complex. This is a fact and there's nothing we can do against it.

From a technical perspective, the Informix evolution was incredible. For those of you who know Informix, just think about the releases that came out inside IBM: 9.3 (little to no influence from IBM because it was launched in 2001), 9.4 (2003), 10 (2005), 11.10 (2007), 11.50 (2008) and 11.7 (2010). By the way, from these, only 9.3 has no support at all and 9.4 and 10 are on limited support. There's value for money here, and investment protection. You can compare this to our main competitor for example. They launched 9i R1, 9i R2, 10g R1, 10 R2, 11g R1 and 11g R2. To the best of my knowledge only latest two are fully supported, so more or less the same number of releases and more supported versions for us. Not bad for a database which had no future ten years ago, I'd say.
If I try to recall all the new features I'll end up with another very large article. But some of them must be mentioned:

9.3
ER in the ORDBMS product line (9.x)
9.4
Larger chunks
ER and HDR at the same time
PAM authentication
B-Tree scanners (as opposed to older B-Tree cleaner)
10
Multiple page sizes
Online index build
Column encryption
External directives
Table level restore
11.10
MACH 11 (multiple secondary nodes)
Non blocking checkpoints
Open Admin Tool
SQL admin API
Database scheduler
Last Committed Read
11.50
Updatable secondaries
Compression
Connection Manager
Start of XPS to IDS feature porting
11.70
Storage provisioning
Non OS users (mapped users)
No limit for the number of extents
On line table reorg
Several XPS features (multi-index path, star join...)
Informix warehous accelerator

And then we get to the marketing perspective... This is the fun part. It's a never ending discussion, and I thought it would be interesting to make some comparisons, like for example quotes versus reality. Announcements versus reality. Declarations of intentions versus reality. I browsed the Internet trying to find what people said and thought at the time and since then.

Let's start a few years before:

"I think Informix is doing a great job of marketing. They now get the Sybase marketing award. It's something we have never done a very good job of. Talk to somebody at Sybase or Microsoft and ask them what they think of DataBlades. Everyone thinks it's crazy. It's not that it's a bad idea -- it's madness. And they did not -- they did not -- integrate those two products. They did not, they cannot, they will not, it's impossible.", Larry Ellison, at InfoWorld interview, February 1997

Actually, we now "activate" ("register" in Informix jargon) datablades automatically if the user calls a function that belong to one of them. And we ship several of them for free. One of them (TimeSeries) is used to beat competition on "smart metering". Other (BTS) is used to incorporate open source text indexing technology into Informix.
On the same article, Larry Ellison mentions that Informix had 4 products. Although he apparently only names 3 (and 2 seem to be the same), this was in part true. There was the "OLTP" engine, the "DW" (XPS) and the Universal Server (IUS). These days are gone. XPS does still exists, although some of it's functionality is in IDS. There is no distinction between OLTP and "object" or universal servers.

By the time of the acquisition:

"We've found in the past is that when you're acquiring other products, the integration problem is greater than the value you gain from acquiring the product. This will be an integration nightmare.", Paul Marriott, business development manager for 9I at Oracle, in ARNnet site, on April 2001

Was this opinion taken into account when Oracle bought JD Edwards, Peoplesoft, Siebel, Hyperion, Innobase, BEA, Sun....? I believe not. Maybe they just don't learn from their "mistakes", or this quote was just another FUD statement...

"Surely Oracle is going to pick up a few customers from you though -especially the Informix customers?

JK; I don't think you can make that general a statement. Oracle is trying to give the impression that we are going to tell the Informix customers that they've now got to move to DB2. But obviously we aren't doing that. We acquired the Informix assets because we value them. We aren't going to force a migration on customers and partners that isn't right for them - that makes no business sense at all. We've spoken to the Informix customers and partners and have told them that Informix will be supported and developed for the foreseeable future - and the Informix customers are very happy with this. They appear to like the whole proposition so we certainly don't anticipate losing them to Oracle." , Jim Kelly, IBM's Vice President, Marketing Data Management Solutions Division, in an interview to an analyst from Bloor Research, on July 2001

AFAIK, no customer was forced to move to DB2. Some customers were forced to move, because their application suppliers (SAP for example) discontinued Informix in their latest versions. These customers had the chance to choose the new database platform. Some choose DB2, others Oracle, others SQL Server (or other databases like SAPdb)... Similar statements were produced by different IBM executives at the time of the acquisition and later.

And just for fun:

"But quite frankly if Informix is still being marketed as an
independent product five years from now I'll be shocked.", Daniel Morgan, an Oracle ACE in comp.databases.oracle.server on June 2001

Hopefully, five or six years after the predicted date, he has already recovered from the shock.

Let's leave the quotes... I'd also like to give you an example of "declarations of intentions vs reality". While working on a project with another IBM product, I felt the need to test something with a competitor (Oracle) database which is used at the customer site. For my purposes the "free edition" was perfectly enough and it allowed me to work on my own environment. I did the download, but after some days I stopped to think about one detail: The current available version of the "free edition" was 10g (launched 4 or 5 years ago). Now... this version is not fully supported anymore (at least without further costs). So I decided to look for a more recent version. Guess what? It' not available. Some more investigation showed me that a new version was made available in April this year, but only for "beta". Now... What on earth is a "beta" version of a free edition?! After all the product should be the same. Only with certain restrictions.
If you want to compare this with the IBM policy for Informix, you'll noticed that the "free edition" is up to date with the latest available fixpack. Do you notice a different behavior here? I do. And I don't think that's because I work for IBM...

On a more personal perspective, from local market, we see that we haven't been loosing customers. More important our customer are very happy with Informix for the well known reasons (reliability, simplicity, robustness, ease of management). This is not marketing. It's a bit hard to point out a true "pure" Informix DBA and I know the biggest installations in my country. We have Informix in some of the biggest retail chains, in the Telcos, in logistics/transportation, in Finance, in central and local administration and in industrial environments. And all of these barely notice that they run Informix. This is a great achievement, but at the same time I feel it's also a downside. Although this is a paradox, I truly believe that a software that has problems may have better chances of success. Why? Because it makes the people who work with it more "visible" when they solve problems.
As an example, in 2010 I was extensively congatulated when I got involved in a critical situation (caused by a sequence of human errors). The issue was escalated to an high level, and after it was solved the appreciation messages and the echos spread across the hierarchical chain. Now... In a normal situation, no problem should have ocurred, and I would still be completely anonymous from a hierachical point of view.
People who manage Informix tend to do other stuff as well and many times they're a bit "invisible". This is not fair since it also means they're doing their job right, but I've seen this happen several times. You probably know the saying... It's better to have "bad publicitly" than no publicity at all...

Now, let's take a look at what changed in Informix (not the new features) since the acquisition:

It gained presence in the IBM events like Information on Demand
We have monthly webcasts (chat with the labs)
We have PIDs (Post Interim Drops) which are cumulative patch updates This means that I rarely ask for a specific patch since most of the time there's a PID with the fix already available
We've been seeing major version releases each 1-2 years (2001,2003,2005,2007,2008,2010). And we've been having new fixpacks each 3 or 4 months which include new features
We have InfoCenter with the most up to date documentation in an easily searchable interface
We still have the PDF documentation for the people who know their ways around the manuals
We have better integration with the IBM product porfolio
Informix is used as a repository for some of these products (Cognos express, Optim as an option...)
Some new features came directly from other products (DB2 for example). Meaning we get improvements with little engineering effort
We have a wider range of editions, including a free one
We are still innovators, as the recent TimeSeries success stories show. There are new requirements and we're able to fulfill them
Informix is a brand inside the IBM Information Management pillar. Remember that at first we were integrated in the "DB2" pillar. Informix is currently on par with DB2, Cognos, Guardium etc.

... And what didn't change:

Informix is still light, easy to install and manage
Informix is still robust
Informix still scales pretty well
Informix support is still good (I'm biased, but I talk a lot with customers that have to deal with other vendors support)
Customers still like Informix
People still complain about the marketing of the product
We don't see Informix in the news
IIUG is still a great asset for the Informix community

I believe most people reading this who are aware of Informix history may consider I looked only at the bright side, and there is a dark side. Things that were not accomplished or things that become worst since the acquisition. But keep in mind that it's not totally fair to compare what happened inside IBM with what happened before IBM (specially during the "golden years"). A fair comparison would have to be done between what would have happened if IBM had not buy Informix, and that's impossible to tell. Naturally every Informix supporter can think that it should have more visibility inside IBM (this is a general idea we pick from the forums and independent blogs and sites), or that we're lacking better marketing etc.
From my point of view the balance is positive. And I'm looking forward to the 20th anniversary after IBM acquisition. Let's see what happens in the next ten years. Ten years ago I think many people would not expect the evolution we had.

Versão Portuguesa

No dia 2 de Julho de 2001 a IBM anunciou a conclusão da aquisição da Informix. Portanto, passaram 10 anos desde o negócio que mudou a vida de muitas pessoas. Muito foi escrito na altura e desde então sobre o negócio, sobre o futuro do Informix, sobre as reacções da concorrência etc. Este marco histórico fez-me olhar para trás e pensar sobre o que se tem passado. Há várias perspectivas sobre isto: A pessoal, a profissional, a técnica e a de marketing (bem como outras que não me ocorrem de momento).
Pessoalmente, a aquisição aconteceu três anos depois de ter ingressado na Informix Portugal. Na altura já estava bastante envolvido com um cliente Português (grande empresa de telecomunicações) e penso que ganhei uma experiência preciosa desde então. Pertencer à IBM deu-me oportunidade de me envolver com outros produtos (de outras áreas, mas que tocam o mundo das bases de dados), embora o foco fosse e ainda o seja, o Informix. O Informix permitiu-me interagir com várias grandes (da perpectiva de um país pequeno) empresas. Portanto foi uma transição muito positiva. Naturalmente nem tudo é perfeito. Escusado será dizer que o ambiente de uma filial (cerca de 20 pessoas na altura) de uma pequena companhia mundial, não é de todo semelhante ao ambiente de uma grande companhia como é o caso da IBM. Os processos dentro de grandes empresas têm necessariamente de ser mais complexos. Isto é um facto e ninguém poderá fazer nada contra isso.

Do ponto de vista técnico, a evolução do Informix foi incrível. Para os que conhecem Informix, basta que recordem as versões que sairam já dentro da IBM: 9.3 (pequena ou nenhum influência da IBM dado que foi lançada em 2001), 9.4 (2003), 10 (2005), 11.10 (2007), 11.50 (2008) e 11.7 (2010). Já agora, destas apenas a 9.3 não tem qualquer tipo de suporte e a 9.4 e 10 estão num esquema de suporte limitado (mas sem custos adicionais). Há aqui valor e protecção de investimento. Pode comparar isto com o nosso maior concorrente: Lançaram o 9i R1, 9i R2, 10g R1, 10 R2, 11g R1 and 11g R2. Tanto quanto julgo saber, só os últimos dois são suportados sem mais custos adicionais, por isso, mais ou menos o mesmo número de releases e maior número delas suportadas por nós. Nada mal para uma base de dados que como muitos diziam não tinha futuro há dez anos atrás.

Se enumerasse as novas funcionalidades acabaria com mais um artigo muito grande. Mas pelo menos algumas devem ser referidas:

9.3
ER na linha de produto ORDBMS (9.x)
9.4
Chunks maiores que 2GB
ER e HDR ao mesmo tempo
Autenticação PAM
B-Tree scanners (em oposição à anterior B-Tree cleaner)
10
Diferentes tamanhos de página
Criação de indíces Online
Encriptação de colunas
Directivas externas
Restore de uma tabela a partir de um arquivo
11.10
MACH 11 (multiplos nós secundários)
Checkpoints sem bloqueio
Open Admin Tool
SQL admin API
Database scheduler
Last Committed Read
11.50
Secundários com possibilidade de alterações (DML)
Compressão
Connection Manager
Início da transposição de funcionalidades do XPS para o IDS
11.70
Storage provisioning
Utilizadores não reconhecidos pelo SO (mapped users)
Eliminação do limite de extents para uma partição
Reorganização de tabelas Online
Várias funcionalidades do XPS (multi-index path, star join...)
Informix Warehouse Accelerator

E agora temos a perspective de marketing.... Este é o aspecto mais divertido. Trata-se de uma discussão sem fim e lembrei-me que seria interessante fazer algumas comparações, como por exemplo citações versus realidade, anúncios versus realidade e declarações de intenções versus realidade. Efectuei umas pesquisas sobre o que as pessoas disseram na altura e desde então.

Comecemos uns anos antes (tradução pessoal. Pode consultar o original nos links):

"Eu penso que a Informix está a fazer grande trabalho de marketing. Eles agora obtêm o prémio de marketing Sybase. É algo em que nós nunca fizemos um bom trabalho. Fale com alguém na Sybase ou Microsoft e pergunte-lhes o que pensam dos Datablades. Toda a gente lhe dirá que é uma loucura. Não é que seja uma má ideia -- é loucura. E eles não -- eles não -- integraram esses dois produtos. Eles não o fizeram, não o podem fazer, não o irão fazer, é impossível.", Larry Ellison, numa entrevista à InfoWorld, em Fevereiro de 1997

Na verdade, nós actualmente "activamos" ("registamos" em linguagem Informix) datablades automaticamente sempre que um utilizador chama uma função que pertence a um deles. E fornecemos vários gratuitamente. Um deles (TimeSeries) é usado para bater a concorrência em "smart metering". Outro (BTS) é usado para incorporar tecnologia de código fonte aberto de indexação de texto, no Informix.
No mesmo artigo, Larry Ellison menciona que o Informix tinha 4 produtos diferentes. Embora aparentemente só refira 3 (e dois parecem ser o mesmo), isto era em parte verdade. Existia o motor "OLTP", o de "DW" (XPS) e o servidor universal (IUS). Esses dias já terminaram. O XPS ainda existe, embora muitas das funcionalidades já estejam no IDS. Não há distinção entre o produto para OLTP e o que na altura era chamado de servidor universal.

Na altura da aquisição:

"Descobrimos no passado que quando adquirimos outros produtos, o problema da integração é maior que o valor ganho pela aquisição do produto. Isto será um pesadelo de integração", Paul Marriott, gestor de desenvolvimento de negócio para o 9I na Oracle, no site ARNnet, em Abril de 2001

Esta opinião foi tida em conta quando a Oracle comprou a JDEdwards, Peoplesoft, Siebel, Hyperion, Innobase, BEA, Sun....? Calculo que não. Talvez não aprendam com os erros ou esta citação tenha sido apenas mais uma a contribuir para o FUD (fear, uncertainty and doubt)...

"Certamente a Oracle irá conseguir obter algums clientes vossos - especialmente clientes Informix?

JK; Não me parece que se possa generalizar essa afirmação. A Oracle está a tentar dar a impressão que nós iremos dizer aos clientes Informix que agora têm de migrar para DB2. Mas obviamente não faremos isso. Adquirimos os bens da Informix porque os valorizamos. Não iremos forçar uma migração em clientes e parceiros que não seja indicada para eles - Isso não faz qualquer sentido em termos de negócio. Temos falado com clientes e parceiros Informix e temos dito que o Informix será suportado e desenvolvido no futuro previsível - e os clientes Informix estão muito contentes com isto. Parecem gostar de toda a proposição de valor e portanto não antecipamos perdê-los para a Oracle", Jim Kelly, IBM's Vice President, Marketing Data Management Solutions Division, numa entrevista a um analista da Bloor Research, em Julho de 2001

Tanto quanto sei, nenhum cliente foi forçado a migrar para DB2. Alguns clientes foram forçados a migrar porque os seus fornecedores aplicacionais (SAP por exemplo) descontinuaram o suporte para Informix nas suas versões mais recentes. Estes clientes tiveram a possibilidade de escolher a nova plataforma para base de dados. Alguns escolheram DB2, outros Oracle e outros SQL Server (ou outras BDs como SAPdb)...
Afirmações semelhantes foram proferidas por outros executivos da IBM na altura da aquisição e após a mesma.

E apenas por brincadeira:

"Mas muito sinceramente, se o Informix ainda for comercializado como um produto independente, daqui a cinco anos ficarei chocado.", Daniel Morgan, um Oracle ACE no comp.databases.oracle.server em Junho de 2001

Com um pouco de sorte, após cinco ou seis anos depois da data prevista, ele já terá recuperado do choque.

Deixemos as citações... Também gostaria de deixar um exemplo de "declarações de intensões versus realidade". Durante um projecto com outro produto IBM, senti a necessidade de testar algo com uma base de dados da concorrência (Oracle), que é usada no cliente onde decorre o projecto. Para as minhas necessidades, a edição gratuita era perfeitamente suficiente e permitia-me trabalhar mais confortavelmente no meu próprio ambiente. Efectuei o download, mas após alguns dias parei para pensar sobre um detalhe: A versão actualmente disponível da edição gratuita era a 10g (lançada há 4 ou 5 anos). Repare-se... esta versão já nem é totalmente suportada (sem custos adicionais). Por isso decidi procurar a versão mais recente. Adivinhe...? Não está disponível. Alguma investigação mostrou-me que a nova versão foi disponibilizada em Abril deste ano, mas apenas em "beta". Agora... O que diabo é uma versão "beta" de uma edição livre?! Ao fim ao cabo o produto deverá ser o mesmo. Apenas com algumas restrições.
Se compararmos isto com a politica da IBM para o Informix, reparamos que a edição gratuita, está a par com os último fixpack disponibilizado. Nota aqui uma diferença de comportamento? Eu noto e julgo que não é por trabalhar na IBM...

Numa perspectiva mais subjectiva, sobre o mercado local, vemos que não temos perdido clientes. Mais importante, os clientes continuam contentes com o Informix pelas razões bem conhecidas (fiabilidade, simplicidade, robustez e facilidade de gestão). Isto não é marketing. É-me um pouco difícil indicar um verdadeiro e "puro" DBA Informix, e conheço as maiores e mais criticas instalações de Informix no meu País. Temos Informix em grandes cadeias de lojas, nas telecomunicações, em logística e transportes, na área financeira, na administração central e local e na área industrial. E em todos estes sitios mal se apercebem que correm Informix. Isto é um grande feito, mas ao mesmo tempo é um grande problema. Apesar de isto ser um paradoxo, acredito verdadeiramente que um software que cause ou esteja envolvido em problemas tem mais facilidade em ter sucesso. Porquê? Porque faz com que as pessoas que trabalhem com ele se tornem mais "visíveis" quando resolvem problemas. A título de exemplo, em 2010 fui extraordinariamente elogiado pelo envolvimento numa situação complicada (originada por uma sequência de erros humanos). O assunto foi escalado ao mais alto nível e após resolvido surgiram os elogios e os ecos percorreram a cadeia hierarquica. Ora numa situação normal, nada de errado teria acontecido e eu continuaria anónimo para a hierarquia.
Quem gere Informix tende a efectuar uma série de outras tarefas. E tendem a ser "invisíveis". Isto não é justo, pois naturalmente significa que estão a fazer o seu trabalho correctamente, mas já o tenho presenciado inúmeras vezes. Como diz o ditado: "que falem mal, mas que falem"...

Vejamos agora o que mudou (não as novas funcionalidades) desde a aquisição:

O Informix ganhou presença nos eventos globais da IBM (como o Information on Demand)
Temos webcasts mensais (chat with the labs)
Temos PIDs (Post Interim Drops) que são patches cumulativos. Isto significa que raramente peço um patch específico pois na maioria dos casos já existe um PID com a correcção necessária já disponível
Temos tido novas versões (major releases) cada 1-2 anos (2001,2003,2005,2007,2008,2010). E temos tido fixpacks cada 3-4 meses, que inclúem novas funcionalidades e não apenas correcções
Temos o InfoCenter com a documentação mais actualizada e uma interface que permite a procura fácil de termos
Continuamos a ter a documentação em PDF para quem já conhece a sua estrutura e prefere tê-la disponível no computador (ou dispositivo móvel)
Temos melhor integração com o portfolio de produtos IBM
O Informix é usado como repositório em alguns dos outros produtos IBM (Cognos Express e Optim como opção, ...)
Algumas novas funcionalidades vieram directamente de outros produtos (DB2 por exemplo). Isto traduz-se em novas melhorias com pouco esforço de engenharia
Temos um leque maior de edições, incluindo uma gratuita
Continuamos inovadores, como as recentes histórias de sucesso com o TimeSeries mostram. Existem novos requisitos e somos capazes de os preencher
Informix é uma marca dentro do pilar de Information Management da IBM. Recorde-se que de início foi incluído no pilar chamado "DB2". O Informix está actualmente a par do DB2, Cognos, Guardium etc.

... E o que não mudou:

Informix ainda é leve, fácil de instalar e gerir
Informix ainda é robusto
Informix ainda é escalável
O suporte Informix ainda é bom (sou suspeito, mas falo muito com clientes que têm de lidar com o suporte de outros vendedores...)
Os clientes ainda gostam do Informix
As pessoas ainda se queixam do marketing em torno do Informix
Continuamos sem ver o Informix nas notícias com frequência
O IIUG continua a sem um bem precioso para a comunidade Informix

Acredito que muitas pessoas ao lerem isto, e conhecendo a história do Informix possam considerar que apenas foquei o lado positivo e que existe um lado negro. Pontos que não foram alcançados ou coisas que correm pior desde a aquisição. Mas convém não esquecer que não é totalmente justo comparar o pós aquisição com o pré-aquisição (especialmente durante os "anos dourados"). Uma comparação para ser justa teria de ser feita entre o que se tem passado dentro da IBM com o que se passaria fora da IBM se não tivesse havido a aquisição. Mas isto é pura especulação. Naturalmente todos os apoiantes do Informix pensam que deveria ter mais visibilidade dentro da IBM (ideia recorrente que se percebe nos forums e em blogs e sites externos à IBM), ou que precisamos de mais/melhor marketing. Mas na minha perspectiva o balanço tem sido positivo. E fico expectante pelo 20º aniversário da aquisição. Vamos ver o que acontece nos próximos 10 anos. Há 10 anos atrás penso que muita gente não acreditaria na evolução que o Informix sofreu.

11.70.xC3 is available / 11.70.xC3 está disponível

2011-06-30T22:53:00.003+01:00

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

My articles backlog keeps increasing, but there are things I can't miss. One of them is the availability of another fixpack of Informix.
The latest one is 11.70.xC3. I spot it on FixCentral a couple of days ago and PDF documentation is already available. InfoCenter is also updated.

As usual there are big news and smaller ones. It really depends on your needs and cares. The follwoing is a straight copy/paste from its release notes:

Administration

Automatic read-ahead operations
Configuring the server response to low memory
Reserving memory for critical activities
Connection Manager enhancements
Enhancements to the OpenAdmin Tool

Embeddability

Managing message logs in embedded and enterprise environments

Developing

Built-in SQL compatibility functions for string manipulation and trigonometric support

High availability clusters and Enterprise Replication

Automatically connecting to a grid
Code set conversion for Enterprise Replication
Enhancements to the Informix Replication plug-in for OAT

Security

Non-root installations support shared-memory and stream-pipe connections
Retaining numbers for audit log files
Restrict operating system properties for mapped users

Time Series data

Simplified handling of time series data
Informix TimeSeries plug-in for OAT

A few remarks:

The possibility of configuring read ahead automatically is great. Let's be honest: How many of us ever really mastered the traditional configuration? Personally I can tell you that a few years ago I tried it in a very controlled environment and I gave up. I could not spot any difference in my tests and over the years I've seen contradictory statements on how it should be setup. So it's a great pleasure to see it can be automatic now.

Server response in a low memory situation is also a great new feature. In cases where I have more than one instance on the same server I insist on setting up SHMTOTAL so that I can isolate any issue caused by excessive memory consumption. This prevents the situation from affecting other instances.
But even so it was usual to see undesirable behaviors on the instance consuming too much memory. And this is easy to understand, because to fix something (rollback, monitor etc.) you still need memory. If you've run out of it, your ability to solve it is constrained.
What IBM did now is give you the ability to reserve some memory, to deal with lack of memory. Seems pretty obvious right? But IBM did more. When you hit the pre-configured thresholds the engine can automatically run some tasks that will allow it to free some memory. So, again, more automation, easier to use in embedded scenarios and more robustness

Connection manager suffered some big changes. Sincerely I need more time to figure them out, but the idea is that a unique connection manager can be used to deal with different needs (high availability, grid, server sets and ER. The configuration file has changed.
As usual, OAT has been changed to accommodate the server side improvements. Several new options are available to deal with log file rotation, low memory conditions setup, lock monitoring (inspired on a plugin initially created by me which is available on the IIUG software repository) and a new plugin to handle TimeSeries.

Several new SQL functions were introduced. This is something that could be solved (most of them could be easily created), but that hurt the new users experience and portability efforts. I would like to see much more in this area...
One interesting new feature is the possibility to configure ER between servers with different codesets. This opens some interesting possibilities for example if you need to convert the codeset of a large database.

Timeseries was also improved, revealing it's one very important aspect of the latests releases.
Finally several security related changes, like improvements for servers in "non-root" installations and for instances configured with mapped users.

I usually concentrate only on the server side improvements, but this time I want to mention a trivial, but long desired change in Client SDK: It now includes dbaccess, the simple but very handy tool. Of course people would like to see a fancy GUI tool on Windows (or even other environments using Java), but that would be much harder, and would certainly increase the footprint.
This is a quick solution for a long lasting problem: the client did not include any query tool. I would vote for the inclusion of other traditional "server side" tools like dbschema and dbload.

Versão Portuguesa

O meu atraso na escrita de artigos continua a aumentar, mas há algumas coisas que não posso deixar passar. Uma delas é a disponibilidade de outro fixpack Informix.
O último é o 11.70.xC3. Encontrei-o há dois dias no site FixCentral e a documentação em PDF já está disponível. O InfoCenter também já está actualizado

Como de costume há grandes novidades e pequenas novidades. Tudo depende das necessidades e preocupações de cada um. O seguinte é a tradução tão fiel quanto possível das novidades especificadas nas notas deste fixpack:

Administração

Operações automáticas de read-ahead
Configuração da reacção do servidor a situações de escassez de memória
Reservar memória para actividades criticas
Melhorias no Connection Manager
Melhorias no OpenAdmin Tool

Funcionalidades de inclusão da base de dados em ambientes fechados

Gestão de logs de mensagens em ambientes embebidos e empresariais

Desenvolvimento

Funções SQL de compatibilidade e manipulação de strings e suporte trigonométrico

Clusters de alta disponibilidade e Enterprise Replication

Conexão automática a uma grid
Conversão de mapas de caracteres para Enterprise Replication
Melhorias no plugin de replicação Informix para o OAT

Segurança

Instalações Non-root suportam conexões shared-memory e stream-pipe
Retenção de números para os logs de audit
Restrição de propriedades de sistema operativo para utilzadores mapeados

Dados Time Series

Gestão simplificada de dados Time Series
Plugin do OAT para Informix TimeSeries

Alguns comentários:

A possibilidade de configurar o read ahead automaticamente parece-me óptima! Sejamos honestos: Quantos de nós conseguiram realmente dominar a configuração tradicional? Pessoalmente posso dizer que há alguns anos atrás tentei num ambiente bastante controlado e desisti. Não consegui identificar diferenças sensíveis nos meus testes, e ao longo dos anos vi indicações contraditórias sobre como isto deveria ser configurado. Por isso é com muita satisfação que vejo que agora pode ser automatizado.

Poder configurar a reacção do servidor em situações de escassez de memória é outra excelente melhoria. Em ambientes onde tenha mais que uma instância por servidor, eu insisto em definir o SHMTOTAL, para que possa isolar qualquer problema causado por excesso de consumo de memória. Isto previne que a situação afecte as outras instâncias (ou no limite a própria máquina). Mas mesmo assim era habitual vermos comportamentos não desejados numa instância que consumisse muita memória. E isto é fácil de entender, porque para corrigir alguma coisa (efectuar um rollback, monitorizar etc.) é necessária memória. Se já a esgotámos, a capacidade de resolver o problema é afectada.
O que a IBM fez agora foi dar-nos a capacidade de reservar alguma memória para lidar com a falta de memória. Parece bastante óbvio, certo? Mas a IBM fez mais. Quando atingimos os limites pré-configurados, o motor pode automaticamente executar algumas tarefas que lhe permitirão libertar memória. Portanto, mais uma vez, mais automatização o que torna mais fácil usar o Informix em ambientes embebidos e aumenta a robustez.

O Connection Manager sofreu grandes alterações. Sinceramente necessito de mais tempo para as analisar, mas a ideia é que um único connection manager pode ser usado para lidar com diferentes necessidades (alta disponibilidade, grid, server sets, e Enterprise Replication). O formato do ficheiro de configuração foi alterado.

Como vem sendo habitual, o Open Admin Tool (OAT) foi alterado para acomodar as melhorias introduzidas no servidor. Novas opções estão disponíveis para lidar com rotação de ficheiros de log, configuração de condições de escassez de memória, monitorização de locks (inspirado num plugin inicialmente criado por mim e disponível no repositório do IIUG) e um novo plugin para lidar com TimeSeries.

Várias novas funções SQL foram introduzidas. Isto é algo que poderia ser resolvido pelo utilizador (a maioria destas podia ser facilmente criada), mas isso dificultava a vida a novos utilizadores e tinha impacto na portabilidade de aplicações. Gostaria de ver muito mais evolução neste aspecto...

Uma funcionalidade interessante é a possibilidade de configurar Enterprise Replication (ER) entre bases de dados que utilizem diferentes mapas de caracteres.
Isto abre possibilidades interessanes se por exemplo necessitar-mos de converter um mapa de caracteres de uma base de dados grande.

O TimeSeries também foi melhorado, revelando que é um dos aspectos mais importantes das últimas versões.
Finalmente, algumas mudanças na área de segurança, como melhorias em servidores instalados como "non-root" e para instâncias configuradas com utilizadores mapeados.

Habitualmente concentro-me apenas nas melhorias do lado do servidor, mas desta vez tenho de mencionar um mudança trivial, mas há muito desejada no Client SDK: Passou a incluir o dbaccess, a ferramenta simples, mas muito útil de interrogação da base de dados. Claro que todos gostaríamos de ver uma ferramenta gráfica nos ambientes Windows (ou mesmo em todos os ambientes, baseado em Java por exemplo), mas a verdade é que isso necessitaria de um esforço muito maior e iria aumentar significativamente a dimensão do cliente.
Isto é uma solução rápida para um problema que existia há muito tempo: o cliente não incluía nenhuma ferramenta de interrogação da base de dados. Eu votaria a favor da inclusão de outras ferramentas "tradicionais" do servidor como o dbschema e dbload.

HP-UX: What now? / E agora?

2011-06-04T13:39:00.000+01:00

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

You know I usually stick to Informix related topics, but a few weeks ago something was announced that has to make us think... As we all know by now, Oracle announced that future versions of their software products will not support HP-UX running on Intel Itanium chips.
Why do we have to think about it? Well, from my personal perspective because it raises a lot of serious doubts/questions. Let's see:

First you read in the announcement that Intel is not truly committed to Itanium. The exact words are "Intel management made it clear that their strategic focus is on their x86 microprocessor and that Itanium was nearing the end of its life". Intel denied this in the following days. Who do we believe? The company that owns the chip in question or another (now also) hardware supplier? Is it normal that a company discontinues it's products on a platform that has not announced it's end of life plans?
The announcement was made just before an important HP shareholders meeting... We could of course believe this was just a coincidence
In the last months a lot of news came up referring to personal wars between Oracle's and HP's executives (ex HP CEO is now a very important Oracle executive). Meanwhile ex SAP CEO has been appointed as HP CEO, and Oracle and SAP had an ongoing court trial started at the time he was SAP's CEO. All these an point 2) may lead us to the feeling that while personalities clash, customers suffer. There's nothing wrong with having strong personalities as leaders of large companies, on the contrary. But we would expect their egos not to cause harm to their customers (of course "harm" translates into costs, uncertainty, fear and doubts - typically FUD that competitors like to spread, but in this case competitors don't have to bother...)
Oracle mentions that others (Microsoft and Red Hat) have previously discontinued support for Itanium. This is true, but there is a big difference: The market share that these two companies had in the Itanium market was considered irrelevant. Now, for Oracle, the situation is completely different. They have a large share of Itanium customers (accordingly to this blog, there are around 140.000 Oracle/Itanium customers)
Some people argue that supporting a platform has it's costs. Of course this is true, but the costs are certainly well covered if the above number holds true. That's part of the business. In order to provide a product, you incur in certain costs. And also note that Oracle always said, wrote an publicized that their code base was the same independently of the platform. So using this as an argument is hardly acceptable...
Many people think this is just a commercial move from Oracle. They're trying to weak a competitor position while at the same time they hope to raise their own hardware sales. We can accept that this is normal, but we should keep in mind a few things. First, just a while ago Oracle choose HP as an hardware partner (remember Exadata?). Secondly Oracle CEO has said that it would like to see Oracle becoming the IBM of the sixties (integrated stack where the margins would be bigger), but that it would keep its software running on competitor platforms. Well something has changed :)
Will this be the only case, or will Oracle do the same in the future with other OS? The fact is that the number of OS and Hardware vendors for enterprise computing is shrinking. You currently have Microsof Windows on Intel x86, IBM AIX on System p, HP-UX on Itanium, Solaris Sparc, Linux on Intel x86, and Solaris on Intel (I'm explicitley forgeting other platforms like IBM System Z and HP NonStop). Oracle is doing it's best to eliminate HP-UX/Itanium. Will it stop there? Or will it proceed it's path to become "the IBM of the 1960s" (meaning the closed system that locked customers in)? Note that IBM still suffers with the image it created at the time.

The above are just a list of some important points. I may be missing a few. The announcement must had a significant impact on HP Itanium customers running Oracle software. Imagine that you wake up one morning and find out that the software vendor you choose gave up supporting your platform. Of course you'll have support for your existing products, but you'd really appreciate a roadmap... By the way, wasn't that the same company that 10 years ago accused IBM of not having a roadmap for Informix? It's funny when we put things into perspective...
So, assuming you're one of those customers what will you do? You have a few options:

You jump on the Oracle train and buy a one way ticket... I mean you choose Sparc for your upcoming hardware renovation... You don't know where the train will take you... You don't even know how much it will cost you... Specially because you just bought a one way ticket... Once you're "there" you'll figure what what price the next ride will cost... One thing you know: You'll be traveling with the same company since no other operates in the same region...
You choose another hardware platform, and you really hope the same trick will not be played again
You change your software supplier

I'd say none of the options above looks particularly attractive. But in case you need another database (and you're able to get your application running against it), you should really consider Informix. Here's why:

It's robust, easy to use, reliable, works well in virtualized environments etc., but you should already know that
It has a roadmap and has just completed a decade of improvements after the IBM acquisition
It belongs to a company that will try to sell you it's hardware, because it believes it's good, and not because it tends to be the only option to run it's software
It's already very well integrated with many of the other IBM software portfolio, and this is assumed to be a continuous effort
It has a long history of working well with HP-UX (traditionally on PA-RISC and now with Itanium). A search for "informix" in the HP site will show you several HP documents about integration between Informix and HP-UX

To wrap up this article, I'd like to put here a few links that relate to this topic. I hope they'll allow you to see what's being written about this Oracle announcement, and to form your own opinion about it.

The original Oracle announcement
http://www.oracle.com/us/corporate/press/346696
The Register article about the announcement
http://www.theregister.co.uk/2011/03/23/oracle_stops_itanium_development/
The Register article covering HP and Intel answer to the announcement
http://www.theregister.co.uk/2011/03/24/intel_hp_itanium_defense/
The Register article overview of the users thoughts about the announcement
http://www.theregister.co.uk/2011/04/26/gabriel_oracle_itanium_survey/
Gabriel Consulting survey referenced in the previous link
http://www.gabrielconsultinggroup.com/recent-research/doc_download/42-oracle-survey-whats-the-real-reason-oracle-dropped-itanium.html
HP echoes some users comments
http://www.hp.com/hpinfo/newsroom/press/2011/110414xa.html?jumpid=reg_R1002_USEN
HP site dedicated to this issue
http://h18004.www1.hp.com/products/solutions/customers_first.html
HP blog from an executive containing a FAQ
http://h30507.www3.hp.com/t5/Mission-Critical-Computing-Blog/FAQs-from-HP-on-the-Oracle-Itanium-Announcement/ba-p/89977

Versão Portuguesa:

Normalmente restrinjo-me a assuntos exclusivamente relacionados com Informix, mas há algumas semanas atrás foi anunciado algo que nos tem de fazer pensar.... Como já todos deveremos saber nesta altura, a Oracle anunciou que futuras versões do seu software não irão suportar HP-UX a correr em chips Itanium.
Porque é que devemos reflectir sobre isto? Bom, na minha opinião pessoal porque isto levanta uma série de dúvidas e questões importantes. Vejamos:

Começamos por ler no anúncio que a Intel não está verdadeiramente empenhada no Itanium. As palavras exactas (tradução pessoal) foram: "... a gestão da Intel deixou claro que o foco da sua estratégia é a linha de processadores x86 e que o Itanium se está a aproximar do fim de vida..." . A Intel negou isto nos dias seguintes. Em quem acreditamos? Na empresa que detém o processador em questão ou noutra empresa (agora também) fornecedora de hardware? Será normal que uma empresa anuncie o fim de desenvolvimento dos seus produtos numa plataforma cujo fim de vida não foi sequer anunciado?
O anúncio foi feito imediatamente antes de um encontro de accionistas da HP.... Podemos claro acreditar que isto foi apenas uma coincidência
Nos últimos meses vieram a público uma série de notícias referentes a guerras pessoais entre executivos da HP e Oracle (o ex CEO da HP é agora um quadro importante na Oracle - o número dois na verdade, logo abaixo do Larry Ellison). Entretanto o ex CEO da SAP foi nomeado CEO da HP, e a Oracle e HP tinham um processo em tribunal que remonta ao tempo em que o mesmo era CEO da SAP. Tudo isto e o ponto 2) podem levar-nos a pensar que enquanto as personalidades se chocam os clientes sofrem. Não há nada de errado em que grandes empresas tenham personalidades fortes na sua liderança, bem pelo contrário. Mas seria de esperar que os egos não prejudiquem os respectivos clientes. O "prejuízo" traduz-se em custos, incerteza, medos e dúvidas - o que em Inglês se chama "FUD - fear, uncertainty and doubt -", que normalmente é espalhado pela concorrência, mas que neste caso nem requer esforço da concorrência pois é feiro pelos próprios.
A Oracle referiu que outros (Microsoft e Red Hat) já tinham previamente descontinuado o suporte para Itanium. Isto é verdade, mas há uma enorme diferença: A quota de mercado que estas duas empresas tinham em Itanium não é comparável à da Oracle. Esta tem uma grande percentagem dos clientes Itanium a usarem os seus produtos (de acordo com este blog, existem cerca de 140.000 clientes Oracle/Itanium)
Algumas pessoas defendem que suportar uma plataforma tem os seus custos. Isto é uma verdade óbvia., mas esses custos são largamente cobertos se os números acima forem correctos. Isso faz parte do negócio. Para fornecer um produto as empresas (de qualquer tipo) incorrem em custos. Note-se ainda que a Oracle sempre disse, escreveu e publicitou que o seu código era o mesmo independente da plataforma. Por tudo isto, o argumento do custo de suportar uma plataforma não me parece aceiável...
Muitas pessoas acreditam que isto é apenas uma manobra comercial da Oracle. Estão a tentar enfraquecer um concorrente ao mesmo tempo que tentam aumentar as suas p´roprias vendas de hardware. Podemos encarar isto como algo relativamente normal, mas devemos manter em mente uma série de factos. Primeiro, apenas há algum tempo atrás, a Oracle escolheu a HP como o seu parceiro de hardware (lembram-se do Exadata?). Segundo, o CEO da oracle disse que gostava de ver (tradução pessoal) A Oracle tornar-se a IBM dos anos sessenta (soluções integradas onde as margens são maiores), mas que manteria o seu software a correr nas plataformas da concorrência. Parece que algo mudou entretanto... :)
Será este um caso único, ou irá a Oracle fazer os mesmo com outras plataformas? A verdade é que as plataformas (SO e hardware) para computação empresarial estão a diminuir. Actualmente temos Microsof Windows em Intel x86, IBM AIX em System p, HP-UX em Itanium, Solaris Sparc, Linux em Intel x86, e Solaris em Intel (estou a omitir outras plataformas como IBM System Z e HP NonStop) . A Oracle está a fazer o seu melhor para eliminar HP-UX em Itanium. Irá parar por aí? Ou irá prosseguir os seu caminho para se tornar a "IBM dos anos sessenta" (neste caso um sistema fechado que prende os clientes)? Note-se que a IBM ainda sofre com a imagem criada nessa altura.

Acima está uma lista de alguns pontos importantes. Posso ter esquecido alguns. O anúncio deve ter tido um impacto significativo nos clientes HP Itanium que utilizam software Oracle. Imagine que acorda uma manhã e descobre que o fornecedor de software que seleccionou, deixou de suportar a sua plataforma. Claro que terá suporte para os produtos que já existem, mas certamente apreciaria a existência de um roadmap... Aliás, não foi esta a mesma empresa que há 10 anos atrás acusou a IBM de não ter um roadmap para Informix? É engraçado quando se colocam as coisas em perspectiva...
Assim, assumindo que é um desses clientes, o que irá fazer? A meu ver tem algumas opções:

Apanha o compboio da Oracle e compra um bilhete de ida... Ou seja, escolhe SPARC para a sua próxima renovação de hardware... Não sabe para onde o comboio o leva... Nem sequer sabe quanto lhe vai custar... Especialmente porque comprará apenas um bilhete de ida... Depois de "lá" chegar logo verá qual o preço da próxima "viagem"... Uma coisa será certa: Irá viajar com a mesma empresa, pois mais ninguém opera na mesma "região"...
Escolhe outra plataforma de hardware e espera ardentemente que o mesmo truque não seja empregue novamente
Muda de fornecedore de softtware

Diria que nenhuma das opções acima parece particularmente atractiva. Mas caso necessite de uma nova base de dados (e possa colocar a sua aplicação a correr nela), deveria considerar o Informix. Eis porquê:

É robusto, confiável, corre bem em ambientes virtualizadoes etc.., mas isto já deverá saber
Tem um roadmap e acabou de completar 10 anos de inovação após a aquisição pela IBMI
Pertence a uma empresa que tentará vender-lhe o seu hardware porque acredita que é bom, e não apenas porque tende a ser a única plataforma onde pode correr o seu hardware
Já está bastante bem integrado com muito do software IBM, e isto é assumidamente um esforço contínuo
Tem uma longa história de bom desempenho em HP-UX (tradicionalmente em PA-RISC e actualmente em Itanium). Uma pesquisa por "informix" no site da HP irá mostrar-lhe vários documentos da HP sobre a integração entre Informix e HP-UX

Para fechar este artigo, gostaria de deixar alguns links relacionados com este assunto. Espero que lhe permitam ver o que tem sido escrito sobre este anúncio da Oracle, e que possa formar a sua p´ropria opinião sobre o tema.

O anúncio original
http://www.oracle.com/us/corporate/press/346696
Um artigo no "The Register" sobre o anúncio
http://www.theregister.co.uk/2011/03/23/oracle_stops_itanium_development/
Um artigo no "The Register" cobrindo as respostas da HP e Intel
http://www.theregister.co.uk/2011/03/24/intel_hp_itanium_defense/
Um artigo no "The Register" sobre as opiniões dos utilizadores sobre o anúncio
http://www.theregister.co.uk/2011/04/26/gabriel_oracle_itanium_survey/
Inquérito do "Gabriel Consulting" referenciado no artigo anterior
http://www.gabrielconsultinggroup.com/recent-research/doc_download/42-oracle-survey-whats-the-real-reason-oracle-dropped-itanium.html
Alguns ecos sobre o assunto publicados pela HP
http://www.hp.com/hpinfo/newsroom/press/2011/110414xa.html?jumpid=reg_R1002_USEN
Um site da HP dedicado ao assunto
http://h18004.www1.hp.com/products/solutions/customers_first.html
Um blog de um executivo da HP que contém um FAQ sobre o tema
http://h30507.www3.hp.com/t5/Mission-Critical-Computing-Blog/FAQs-from-HP-on-the-Oracle-Itanium-Announcement/ba-p/89977

Informix Roadshow 2011 Lisboa (report)

2011-05-17T23:40:00.003+01:00

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

The Lisbon Informix Roadshow 2011 was a success. We got a full room of customers and partners to learn about the latest news in the Informix world.
We had international speakers (Juan Brogeras - SWG Information Management Sales Director SPGI, Steve Shoaf - WW sales Executive - Informix and solidDB, Jose Manuel Ruiz Gallud - Informix Technical Sales - Southwest IOT and Manuel Jorge Sousa - Vice President 4JS for Iberia)

Juan started the sessions with an overview of the Informix business, followed by Steve which explained what Informix Warehouse is and what you can do with it. This was one of the hottest topics.
Manuel proceeded with an excellent overview of 4JS and what the new partnership can bring to customers.
After the break Jose gave us the news on 11.7. By obvious reasons this was another session that raised the assistance interest.
We ended up with a client presentation from PTSI. Eduardo Santana explained us how they migrate all their Informix environments to 11.50. We found out how they did it, what they achieved and what they plan to do next to take advantage of the new features.
I wrapped the session with an overview of the information available on the IBM site about Informix, more specifically the ROI tools, the analyst studies, the documentation, the several editions and the redbooks.
After that we had lunch "outside" which given the weather was a very nice idea. Of course during the break and lunch we had plenty of opportunities to interact with customers and partners and it really made my day receiving the positive feedback about the sessions.

Above you can see Jose Ruiz in action, updating us with all the new benefits of Informix 11.7

Versão Portuguesa:

O Informix Roadshow 2011 de Lisboa foi um sucesso. Tivemos uma sala cheia de clientes e parceiros que desejavam obter as últimas novidades sobre o mundo Informix.

Estre os oradores tivemos alguns com responsabilidades internacionais (Juan Brogeras - SWG Information Management Sales Director SPGI, Steve Shoaf - WW sales Executive - Informix and solidDB, Jose Manuel Ruiz Gallud - Informix Technical Sales - Southwest IOT and Manuel Jorge Sousa - Vice Presidente 4JS para a Iberia)

Juan iniciou as sessões com um apanhado do negócio Informix, seguido pelo Steve que explicou o que é o Informix Warehous Accelerator e o que podemos fazer com ele. Esta foi uma das sessões que mais atenção suscitou.
O Manuel prosseguiu com uma excelente visão da 4JS e o que esta parceria pode trazer aos clientes.
Depois do intervalo o Jose mostrou-nos as novidades da 11.7. Por razões óbvias esta foi outra sessão que despertou mais interesse na assistência.
Terminámos com uma apresentação de um cliente, a PTSI. O Eduardo Santana explicou-nos como é que migraram todos os seus ambientes para a versão 11.50. Descobrimos como o fizeram, o que alcançaram e o que pensam fazer para tirar proveito das novas funcionalidades.
Eu encerrei a sessão com uma descrição da informação disponível no site da IBM sobre Informix, mais especificamente as ferramentas de cálculo de ROI (return on investment), os estudos de analistas, a documentação, as várias edições disponíveis e os redbooks.
Após isso tivemos oportunidade de almoçar "fora", o que dado o bom tempo que se fazia sentir tornou a refeição mais agradável. Naturalmente que durante o intervalo e o almoço tivemos oportunidade de interagir com clientes e parceiros e foi com prazer que recebemos feedback positivo sobre as várias sessões.

Em cima podem ver o Jose Ruiz em acção, actualizando-nos com todos os benefícios do Informix 11.7

IIUG 2011: Last call / Ultima chamada

2011-05-09T22:30:00.004+01:00

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

The 2011 International Informix User Group conference is just around the corner. It will take place in Lenexa, Kansas City between 15 and 18 May. The conference site has all the information you may need. This includes the sessions abstracts, the list of tutorials, hotel and transportation information etc.

And what a great conference this will be. Remember that we have Informix 11.7, Informix Warehouse Accelerator and the Genero partnership with 4Js.
And then you have all the permanent/usual attractions, like deep technical sessions, keynote speakers, the Sunday tutorials etc. Some of my personal favorites this year would be:

Sunday tutorials (Flexible grid, Fastest Informix DBA, Partitioning, Certification preparation)
Keynote speakers (Jerry Keesee - Director of Informix Database Development, Rob Thomas - Vice President of Business Development, Arvind Krishna - General Manager IBM Information Management) including this year's special with Dr. David Ferrucci the lead researcher and Principal Investigator (PI) for the Watson/Jeopardy! project
These are great opportunities to understand IBM plans and to ask the difficult questions
Several sessions on specific topics like Informix 11.7, Informix Warehouse Accelerator, Performance and Tunning, integrating Informix with other products
Free certification opportunity
Networking with many people from the Informix community
Evening specials... Great fun to trigger networking

As I observed in last year's conference, the IIUG team does everything possible to provide you the best value for money. And they, together with all the people delivering sessions in the conference, really manage to provide great sessions, great tutorials and great entertainment.

If you never had the opportunity to go to one of the IIUG's conferences you really don't know what you're missing. If you had, you know it's worth it. Unfortunately this year I won't be able to join, but I'm eagerly waiting for feedback from the community and to check the presentation materials. To all the lucky attendees I wish you a great conference, and please blog/email about it!

Versão Portuguesa:

A conferência de 2011 do grupo internacional de utilizadores de Informix está quase a acontecer. Terá lugar em Lenexas, Kansas City entre 15 e 18 de Maio. O site da conferência tem toda a informação possível. Isto incluí as sinapses das sessões, a lista de tutorials, informação sobre o hotel e transportes etc.

E tudo indica que esta será uma grande conferência. Lembremo-nos que temos a versão 11.7 do Informix, o Informix Warehouse Accelerator e a parceria Genero com a 4JS.
Para além disso teremos as atracções habituais, como sessões muito técnicas, os oradores especiais, os tutorials de domingo etc. Alguns dos meus favoritos detes ano seriam:

Tutorials de domingo (Flexible grid, Fastest Informix DBA, Partitioning, Preparação para certificação)
Oradores especiais (Jerry Keesee - Director de Informix Database Development, Rob Thomas - Vice Presidente de desenvolvimento de negócio, Arvind Krishna - General Manager IBM Information Management) incluindo uma participação especial do Dr. David Ferrucci - lead researcher and Principal Investigator (PI) para o projecto Watson/Jeopardy!
São grandes oportunidades para entender os planos da IBM e para colocar as questões difíceis
Várias sessões sobre tópicos específicos como Informix 11.7, Informix Warehouse Accelerator, Performance e optimização, integração de Informix com outros produtos
Oportunidade para obter a certificação gratuitamente
Convivio com imensas pessoas da comunidade Informix
Animação nocturna... Muito divertimento para proporcionar o convivio e interacção entre os participantes

Como pude observar na conferência do ano passado, a equipa do IIUG faz tudo o possível para proporcionar o melhor retorno do investimento. E eles, juntamente com quem apresenta as sessões, conseguem realmente providenciar óptimas sessões, excelentes tutorials e muito entretenimento.

Se nunca teve a oportunidade de participar numa das conferências do IIUG então não sabe o que perde. Se já teve, então sabe que valem a pena. Infelizmente este ano não me vai ser possível participar, mas fico ansioso pelo feedback da comunidade e para espreitar as apresentações quando estiverem disponíveis. A todos os felizardos que vão assistir á conferência, desejo um excelente evento, e por favor bloguem ou contem na lista de mail como está a ser.

Informix Roadshow 2011 Lisboa (Agenda)

2011-04-18T01:30:00.000+01:00

This article is only written in Portuguese due to it's local nature
Este artigo só está escrito em Português dada a sua natureza local

A agenda do evento Informix Roadshow 2011 a realizar no próximo dia 3 de Maio nas instalações da IBM é:

AGENDA:

9:45 Registo e Boas Vindas
10.00 – 10.15 Discover the Next Decade of Informix at IBM
Juan Brogeras - SWG Information Management Sales Director SPGI
10.15 – 10.45 Informix UltimateWarehouse.Transformational and Continuous Improvements for Your DataWarehouse.
Steve Shoaf -WWSales Executive - Informix & solidDB
10.45 – 11.15 Informix Genero: Broadening the Informix 4GL Portfolio.
Manuel Jorge Sousa - Vice President 4Js for Iberia
11.15 – 11.45 Café
11.45 – 12.15 Informix 11.7 solutions, features, roadmap and evolution
José Manuel Ruiz Gallud - Database Sales, Southwest IOT
12.15 – 12.45 Upgrading Informix Dynamic Server / Case study.
12.45 – 13.15 Testemunho de um Informix Business Partner
13.15 – 13.30 Wrap up / Almoço

Faça a sua inscrição através do email ibmdm@pt.ibm.com
Estacionamento gratuito no parque do Hotel Vip Art’s (mesmo em frente ao Edf IBM no Parque das Nações em Lisboa)

Informix Roadshow 2011 Lisboa

2011-04-13T23:56:00.004+01:00

This article is written only in Portuguese due to it's local nature
Este artigo só está escrito em Português dada a natureza local

Versão Portuguesa:

A IBM vai realizar o Informix Roadshow 2011 no dia 3 de Maio, no IBM Fórum Lisboa (instalações da IBM no Parque das Nações).
Será meio dia dedicado às últimas novidades da família Informix. Em particular:

Funcionalidades da versão 11.7 (Panther)
Informix Warehouse Accelerator
Informix Genero

Comemoram-se este ano os primeiros 10 anos após a aquisição da Informix, pelo que será apresentado um balanço desta década e lançamento das bases para a próxima
As sessões contarão com oradores nacionais e internacionais. Haverá tempo para questões e interação entre clientes, parceiros e equipa IBM.
Não deixe se comparecer e se não receber convite nos próximos dias não deixe de contactar a IBM ou a mim pessoalmente.
No final das sessões será proporcionado um almoço onde terá toda a equipa IBM e oradores à sua disposição para qualquer esclarecimento adicional.
O convite é extensível a todos os que não sendo clientes ou parceiros desejem conhecer melhor uma base de dados fiável, robusta, rápida, moderna, extensível e especialmente adaptada para ambientes "embebidos".

Finalmente, mantenha-se atento a este espaço para obter informação mais detalhada sobre a agenda.

New products / Novos produtos

2011-04-05T01:10:00.000+01:00

This article is written in English and Portuguese
Este artigo está disponível em Inglês e Português

English version:

Informix Warehouse Accelerator

There are several news in the Informix area. As I mentioned in the last article, version 11.7.xC2 is already available (including the update on the documentation center), but that's not all. One of the major features of 11.7.xC2 is that it supports a new product called Informix Warehouse Accelerator. This is a separate installable component, that uses a columnar based approach and holds copy of certain groups of tables (datamarts). The data is stored in memory and the queries that can be solved by this system are transparently sent from the main instance. If the data you're querying is not stored/duplicated in the system than the query is solved by the Informix instance. The principle is terribly simple and the installation and configuration is very straight forward. The Accelerator is only available for Linux x86_64 but can work together with Informix on other platforms. The product includes an eclipse based tool to manage the data mapping and configuration of your Informix instance. The product is oriented for data warehouse workloads and was already available for DB2 on z/OS.
The Informix Ultimate Warehouse Edition includes the usual Informix features, the Warehouse Accelerator, compression, LBAC, replications etc.
I've done a few preliminary tests and I can assure you the configuration is very easy. Expect some details in a future article. Meanwhile you can start discovering it at the following URL:

http://www-01.ibm.com/software/data/informix/ultimate-warehouse-edition/

Informix Genero

Informix Genero is another new product targeting the 4GL users. You may recognize the name as a 4JS product. It enables the modernization of 4GL applications (new interface, new functionalities, new deployment environments).

I've seen lots of customers with very customized, flexible and stable applications running with Informix 4GL that complain about the looks (character based) and some lack of functionalities. Nevertheless they don't want to leave 4GL for several reasons:

4GL productivity
Programmers mindset (4GL is a procedural language, and moving to object oriented is not always easy)
Ease of debug
Stability
etc.

If you're one of this customers you may want to take a close look at this new IBM offer. Please start here:

http://www-01.ibm.com/software/data/informix/tools/genero.html

Partners conference calls:

If you have interest in these two topics, you can try to check these two partner conference calls:

Informix Ultimate Warehouse Editions:
April 5, at 10:00 Eastern Time (for Americas and EMEA)

https://events.webdialogs.com/register.php?id=5585aaa88c&l=en-US

April 5, at 20:00 Eastern Time (for Asia and Pacific)

https://events.webdialogs.com/register.php?id=aff9b337a3&l=en-US

Informix Genero
April 7, at 10:00 Eastern Time (for Americas and EMEA)

https://events.webdialogs.com/register.php?id=ca67bb2acd&l=en-US

April 7, at 20:00 Eastern Time (for Asia and Pacific)

https://events.webdialogs.com/register.php?id=6b389b0604&l=en-US

Versão Portuguesa:

Informix Warehouse Accelerator
Há várias noticias na área de Informix. Como mencionei no último artigo, a versão 11.7.xC2 já está disponível (incluindo a actualização no centro de documentação), mas não é tudo. Uma das funcionalidades da 11.7.xC2 é suportar um novo produto chamado Informix Warehouse Accelerator. Este é um componente instalado separadamente, que usa uma abordagem orientada a colunas e que guarda uma cópia de vários groupos de tabelas (datamarts). Estes dados são guardados em memória e a queries que possam resolver-se no novo sistema serão enviadas transparentementde pelo sistema principal. Se os dados não que estamos a interrogar não existirem neste sistema, então a query é resolvida pelo sistema principal. O princípi é terrivelmente simples bem como a configuração e instalação. O Accelerator só existe para Linux x86_64 (mas pode estar ligado a uma instância Informix noutra plataforma). O produto incluí uma ferramenta baseada no Eclipse que permite a gestão dos mapeamentos de dados e a configuração da instância Informix. O produto é orientado a ambientes de data warehouse e já estava disponível para DB2 em z/OS.
O Informix Ultimate Warehouse Edition incluí as funcionalidades habituais do motor, o Warehouse Accelerator, compressão LBAC, replicação etc.
Já tive oportunidade de fazer alguns testes preliminares e posso assegurar que a configuração é de facto muito fácil. Aguarde mais detalhes num futuro artigo. Entretanto pode começar a descobrir o assunto no seguinte URL:

http://www-01.ibm.com/software/data/informix/ultimate-warehouse-edition/

Informix Genero

O Informix Genero é outro produto cujo alvo são os utilizadores de 4GL. Talvez reconheça o nome como um produto da 4JS. Permite a modernização de aplicações 4GL (novo interface, novas funcionalidades, novos ambinetes de utilização).

Tenho visto muitos clientes com aplicações muito adaptadas, fléxivies e estáveis que sistematicamente se quixam do aspecto (baseado em caracter) e alguma falta de funcionalidades.
No entanto não querem deixar o 4GL por várias razoes.:

Produtividade do 4GL
Orientação dos programadores(4GL é uma linguagem procedimental e a mudança para programação orientada a objectos nem sempre é fácil)
Facilidade de despiste de problemas
Estabilidade
etc.

Se é um destes clientes, talvez queira dar uma olhadela nestas novas ofertas da IBM: Comec aqui:

http://www-01.ibm.com/software/data/informix/tools/genero.html

Conferências para parceiras;

Se tem interesse em algum destes tópicos pode tentar assistir a estas duas reuniões

Informix Ultimate Warehouse Editions:

5 de Abril, às 10:00 Eastern Time (para as Americas e EMEA)

https://events.webdialogs.com/register.php?id=5585aaa88c&l=en-US

5 de Abril, às 20:00 Eastern Time (para a Asia e o Pacifico)

https://events.webdialogs.com/register.php?id=aff9b337a3&l=en-US

Informix Genero
7 de Abril, às 10:00 Eastern Time (para as Americas e EMEA)

https://events.webdialogs.com/register.php?id=ca67bb2acd&l=en-US

7 de Abril, às 20:00 Eastern Time (Asia e Pacifico)

https://events.webdialogs.com/register.php?id=6b389b0604&l=en-US

Informix 11.70.xC2: It's out!

2011-03-28T22:01:00.003+01:00

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English Version:

It's been too long since my last post. The reason is the usual lack of time. Sorry for that...
This is just a small post to let you know that Informix version 11.70.xC2 is being made available. It's already possible to get if from the Fix Central site (link on the right). The Information Center documentation site is still not updated. But a quick look into the release notes shows some interesting stuff:

Installation without root privileges
This makes it possible to install and use Informix without root privileges. But due to the Unix/Linux nature, some features may not be available. This was a request from some embedded solutions providers. So it's another feature that helps make Informix the right choice for those environments. I believe we'll see more developments in the usage without root privileges in the future.
More SQL Admin API commands
This time will see things like CREATE/DROP DATABASE and ONTAPE/ONBAR/ONSMSYNC commands. This is great since you can trigger your backups as tasks. Something that we're missing.
More improvements in the BTS text search datablade. IBM continues to improve this datablade which it free of charges
Table and column ALIASES in DML instructions (SELECT, DELETE and UPDATE)
The ALIAS can now be used in GROUP BY clauses. I like this one. We could use numbers, but if you change your projection list you also need to change the GROUP BY clause.
Case insensitive searches
This was also a frequently asked for feature. It applies only to NCHAR and NVARCHAR fields and you need to specify it in the CREATE DATABASE statement
OAT improvements
As usual, when we see engine improvements we also see them in OAT. This time, a new area lets you manage your backups. Other features include the ability to uninstall a plug-in (something I also missed), ability to create reports based on historical data, improvements in the schema manager plugin-in and a few more
Ability to configure the number of file descriptor servers
This is an intriguing feature related to a nasty problem that affects Informix instances with very intensive usage (I'm talking about thousands of concurrent connections, and a very high rate of new connections per second - typical values lay in the vicinity of more than 2000 concurrent sessions and/or more than 15 new connections per second, but it really depends on the environment). This issue is worth a dedicated article, and tech support usually knows it by "nsf.lock issue". If you never heard about it, it's because you don't suffer from it. In any case, this feature is in fact present in several older versions (later v10 fixpacks and 11.50). Unfortunately it was not properly documented. Also note that v11.7 has some structural changes that should eliminate this problem. The feature is translated into a new parameter called NUMFDSERVERS. Classical versions (pre v10.??) used just one. Somewhere in the v10 family it was decided that more was better, but sometimes it isn't due to other points of contention (eliminated in v11.7). So now you can decide how many to use.
Informix Warehouse Accelerator
This is a new product that uses new technology. It is composed of a new in-memory based query engine, and a tool you use to map your OLTP data into that new system. Then, when you send DSS like queries to the OLTP engine, it will decide if the "partner" system can handle them. If it does the query is routed transparently and the results sent back. If it doesn't than the OLTP will resolve the queries. The advantage is that you get much (really!) faster query times on the queries routed to the new system. There was a preview of these technology on IIUG conference last year and the results were impressive. Please be alert, because there will be some buzz around this (the same technology is already available on DB2 for z/OS)

In short that's it. And there as with any other fixpack there are some bug fixes.

Versão Portuguesa:

Passou muito tempo desde o último artigo. A razão é a habitual falta de tempo. As minhas desculpas...
Este artigo serve apenas para dar conta de que a versão 11.7.xC2 do Informix está a ser disponibilizada. Já é possível obtê-la do site Fix Central (ligação à direita). A documentação no Information Center ainda estará a ser actualizada. Mas uma pequena espreitadela nas release notes mostra algumas coisas interessantes:

Instalação sem privilégios de root.
Isto torna possível instalar e utilizar o Informix sem privilégios de root. Mas dada a natureza dos sistemas operativos Unix/Linux, algumas funcionalidades poderão não estar disponíveis. Isto foi um pedido de alguns fornecedores de soluções embebidas. Por isso é mais uma funcionalidade que ajuda o Informix a ser a escolha acertada para este tipo de ambientes. Acredito que iremos ver mais desenvolvimentos relativos à utilização sem root no futuro
Mais comandos da API de administração SQL
Desta vez vemos comandos como CREATE/DROP DATABASE e ONTAPE/ONBAR/ONSMSYNC. Isto é óptimo pois passamos a poder despoletar backups como tarefas. Algo que já se sentia falta
Mais melhorias no datablade de pesquisa de texto livre (BTS)
A IBM continua a melhorar este datablade que é distribuído sem custos com o produto
ALIAS em tabelas e colunas nas instruções de DML ((SELECT, DELETE and UPDATE)
Os ALIAS podem agora ser usados nas cláusulas de GROUP BY. Pessoalmente agrada-me bastante. Já podíamos usar números, mas se mudássemos a projection list teríamos também de arranjar a cláusula GROUP BY
Pesquisas por caracteres não sensíveis a maiúsculas ou minúsculas
Esta funcionalidade fazia parte da lista com mais pedidos. Só se aplica a colunas NCHAR e NVARCHAR e tem de ser especificada na criação da base de dados (instrução CREATE DATABASE)
Melhorias no OAT
Como vem sendo hábito, sempre que temos melhorias no motor também as vemos no OAT. Desta vez, uma nova área permite gerir os backups. Outras novidades inclúem a possibilidade de desinstalar plug-ins (algo que sentia falta), criação de relatórios baseados em dados de histórico, melhorias no plug-in de gestão de schema e mais alguns
Possibilidade de configurar o número de servidores de file descriptors.
Isto é uma funcionalidade algo intrigante, relacionada com um problema complexo que afecta instâncias Informix com uma utilização muito intensiva (estou a falar de milhares de sessões concorrentes e uma taxa muito alta de novas sessões por segundo - valores tipicos situam-se perto de mais de 2000 sessões concorrentes e/ou mais de 15 novas sessões por segundo, mas dependerá sempre de cada ambiente)
Este assunto mereceria por si só um artigo, mas o suporte técnico reconhece-o por "problema do nsf.lock". Se nunca ouviu falar nele é porque nunca sofreu com ele. Em qualquer caso, esta funcionalidade está de facto presente em várias versões já antigas (últimos fixpacks da versão 10 e fixpacks da versão 11.50). Infelizmente não estava devidamente documentadas. Note-se também que a versão 11.7 tem algumas modificações estruturuais que deverão eliminar este problema. A funcionalidade traduz-se num novo parâmetro chamado NUMFDSERVERS. Versões antigas (pre v10.??) usavam apenas um servidor de file descriptors. Num determinado fixpack da versão 10 considerou-se que mais era melhora, mas em alguns casos não é, devido a outros pontos de contenção (eliminados na versão 11.7). Assim, agora podemos decidir e ajustar quantos queremos
Informix Warehouse Accelerator
Isto é um novo produto que utiliza tecnologia nova. É composto por um motor de queries, baseado em memória, e uma ferramenta que pode usar-se para mapear alguns dados do sistema OLTP neste novo sistema. Depois, quando enviados uma query do tipo DSS ao motor OLTP, ele decide se o novo sistema associado pode resolver a query. Se sim, a query é enviada transparentemente ao novo sistema, e os resultados são enviados de volta. Se a query não puder ser processada pelo sistema "emparceirado", então o sistema OLTP irá resolvê-la. A vantagem é que obteremos muito (mesmo muito!) melhores tempos de execução nas querys enviadas ao novo sistema. Houve uma antevisão do sistema na última conferência do IIUG e os resultados eram realmente impressionantes. Mantenha-se alerta, pois isto irá certamente dar que falar nos próximos tempos (a mesma tecnologia já existe para DB2 em z/OS)

Em resumo é isto. E como em qualquer outro fixpack contém igualmente um número de correcções.

Informix making the world smarter...

2011-01-26T01:14:00.003Z

This article is written only in English
Este artigo apenas está disponível em Inglês

Although I'm preparing some technical articles I'm happy to make a break to echo some good news...

Informix is helping an IBM Partner, Centric Solutions, in making the world smarter. Bank of China is using it for a SWIFT application, that also helps to save trees.

These are my words, but I think everyone agrees it must be robust, fast and trustworthy... and Informix is a perfect match for that!

Read all about it here:

http://www.prnewswire.com/news-releases/bank-of-china-in-the-uk-works-with-ibm-to-become-a-smarter-greener-bank-114573679.html

Stored procedure PDQ / PDQ dos procedimentos

2011-01-09T00:40:00.005Z

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

A few years ago I needed to check if I had some stored procedures created with PDQ. Maybe some readers don't know, but if you have SET PDQPRIORITY n in your session before creating a procedure it will run with that PDQ. And that can cause abnormal resource consumption. In most cases you'll want your procedures created without PDQ.
The PDQ associated with a procedure will also change if you run UPDATE STATISTICS FOR PROCEDURE [...], in a session with PDQ active. This is also a frequent issue when people forgot to turn it off or when the statistics are gathered for tables (where PDQ can be helpful) and procedures on the same command or script.

So, how to check the PDQ of your procedures? The catalog tables don't provide this information, so at the time I asked for help internally within IBM. Cosmo, from UK came to my rescue with a strange query that I used successfully a couple of times. The query checks the first 3 characters of the column "data" from sysprocplan where planid = -2.... Don't ask... supposedly this is an encode of the PDQ value.
Recently I had another situation on a customer, where we suspected they had their procedures with PDQ. We were expecting to see the value of 80 (which we caught in some sessions) but all we saw was NULL. Once again I asked Cosmo for help, and during our conversations we noticed that we only had run the query on little endian platforms (Linux on Intel and Tru64). So, Cosmo sent me a script that created 100 procedures with different PDQ levels and then returns the encoded values. It was no surprise that the values were different. Following Cosmo's suggestion I joined both set of values into a big CASE statement that you can check at the end of this article.

The query has a few important points:

I used data[1,3] in the CASE statement. We could use data::CHAR(3), but with that it would not run on version 7. It's not supported anymore, but there are still people using it, so I decided to use a syntax that's compatible with those old versions.
If I remember correctly Cosmo's first query was really a function that received the procedure name. I'm including that as another option in the end of the article. In that version the query raises and error if it enters the ELSE condition of the CASE statement. In the version I was using at the later customer, the case returned NULL and that fulled me... In this new version it will raise an error since it means there is something wrong with the query.
For the non-procedural version, I did a small and dirty trick: If it enters the ELSE condition it will try to return a value divided by zero. This will cause an error.
Note that this conditions can't happen because the PDQ must be a value between 0 and 100. So if in the future the encoding changes the query will start raising errors, and this should alert the user...
The encoded values for PDQ 1 to 100 are distinct in the two types of platforms. The encoded value for 0 however is equal. That's why we have two WHEN conditions for each value between 1 and 100 and just one for 0.

Versão Portuguesa:

Há alguns anos atrás precisei de verificar se tinha criado algum procedimento com PDQ. Talvez alguns leitores não saibam, mas se tivermos executado SET PDQPRIORITY n na sessão antes de criar um procedimento, este irá ser executado com esse valor de PDQ. E isso pode causar um consumo anormal de recursos. Na maioria das situações não queremos ter procedimentos criados com PDQ.
O PDQ associado a um procedimento também muda se corrermos um UPDATE STATISTICS FOR PROCEDURE [...], numa sessão com PDQ activo. Isto é um problema habitual quando nos esquecemos de desligar o PDQ, ou quando as estatísticas são criadas para tabelas (processo onde o PDQ é benéfico) e procedimentos no mesmo comando ou script.

Como podemos verificar o PDQ dos procedimentos? As tabelas do catálogo não disponibilizam esta informação, por isso na altura pedi ajuda internamente na IBM. O Cosmo, de UK, auxiliou-me com o envio de uma query um pouco estranha que usei algumas vezes com sucesso. A query verifica os três primeiros caracteres de uma coluna "data" da tabela sysprocplan, onde "planid = -2"... Não pergunte... É suposto isto ser o valor de PDQ codificado de alguma forma.
Recentemente tive outra situação num cliente onde suspeitávamos que tinham os procedimentos com PDQ. Esperávamos ver o valor 80 (que tinhamos visto activo em algumas sessões), mas tudo o que a query nos dava era NULL. Note-se que se tivesse olhado bem para a query deveria ter percebido que o NULL implicava um erro. Mas como estávamos à espera de ver um valor (80) cometi um "erro de simpatia". Recorri novamente ao Cosmo para ajuda. E durante as nossas trocas de impressões notámos que só tinhamos corrido a query em plataforms que usam little endian (Linux em Intel e Tru64). Assim o Cosmo enviou-me um script que cria 100 procedimentos com diferentes valores de PDQ e que retorna os respectivos valores codificados. Não foi surpresa ver valores diferentes. Seguindo uma sugestão do Cosmo, juntei ambos os conjuntos de valores numa instrução CASE que pode ser consultada no final deste artigo.

A query tem alguns pontos importantes:

Utilizei data[1,3] na instrução CASE. Podíamos utilizar data::CHAR(3), mas com isso a query não correria na versão 7. Esta versão já está sem suporte, mas ainda é usada, por isso preferi uma sintaxe compatível com versões mais antigas
Se bem me recordo a primeira query que o Cosmo me enviou, era na realidade uma função que recebia o nome do procedimento que queríamos verificar. Esta forma está também incluída no final do artigo. Nesta forma o código causa um erro caso entre na condição ELSE do CASE. Na versão que estava a usar neste último cliente, o CASE retornava NULL e isso enganou-me... Nesta versão actualizada e corrigida, irá gerar um erro, dado que isso implica que algo não está correcto na query. Não versão não procedimental incluí um pequeno truque: Se entrar no ELSE do CASE vai tentar retornar um valor a dividir por zero. Isto irá causar um erro.
Note-se que esta condição não pode acontecer pois o PDQ será sempre um valor entre 0 e 100. Se no futuro os valores codificados forem alterados a query deverá começar a dar erro, e isso deverá alertar o utilizador...
Os valores codificados de PDQ de 1 a 100 são distintos nos dois tipos de plataforma (little endian e big endian). No entanto o valor codificado para 0 é igual. É por isso que temos duas condições WHEN para cada valor entre 1 e 100 e só um para o valor 0.

Non-procedural query:
Query não procedimental:


SELECT
 f.procname,
 CASE data[1,3]
     WHEN "AAA" THEN 0
     WHEN "AQA" THEN 1
     WHEN "AAE" THEN 1
     WHEN "AgA" THEN 2
     WHEN "AAI" THEN 2
     WHEN "AwA" THEN 3
     WHEN "AAM" THEN 3
     WHEN "BAA" THEN 4
     WHEN "AAQ" THEN 4
     WHEN "BQA" THEN 5
     WHEN "AAU" THEN 5
     WHEN "BgA" THEN 6
     WHEN "AAY" THEN 6
     WHEN "BwA" THEN 7
     WHEN "AAc" THEN 7
     WHEN "CAA" THEN 8
     WHEN "AAg" THEN 8
     WHEN "CQA" THEN 9
     WHEN "AAk" THEN 9
     WHEN "CgA" THEN 10
     WHEN "AAo" THEN 10
     WHEN "CwA" THEN 11
     WHEN "AAs" THEN 11
     WHEN "DAA" THEN 12
     WHEN "AAw" THEN 12
     WHEN "DQA" THEN 13
     WHEN "AA0" THEN 13
     WHEN "DgA" THEN 14
     WHEN "AA4" THEN 14
     WHEN "DwA" THEN 15
     WHEN "AA8" THEN 15
     WHEN "EAA" THEN 16
     WHEN "ABA" THEN 16
     WHEN "EQA" THEN 17
     WHEN "ABE" THEN 17
     WHEN "EgA" THEN 18
     WHEN "ABI" THEN 18
     WHEN "EwA" THEN 19
     WHEN "ABM" THEN 19
     WHEN "FAA" THEN 20
     WHEN "ABQ" THEN 20
     WHEN "FQA" THEN 21
     WHEN "ABU" THEN 21
     WHEN "FgA" THEN 22
     WHEN "ABY" THEN 22
     WHEN "FwA" THEN 23
     WHEN "ABc" THEN 23
     WHEN "GAA" THEN 24
     WHEN "ABg" THEN 24
     WHEN "GQA" THEN 25
     WHEN "ABk" THEN 25
     WHEN "GgA" THEN 26
     WHEN "ABo" THEN 26
     WHEN "GwA" THEN 27
     WHEN "ABs" THEN 27
     WHEN "HAA" THEN 28
     WHEN "ABw" THEN 28
     WHEN "HQA" THEN 29
     WHEN "AB0" THEN 29
     WHEN "HgA" THEN 30
     WHEN "AB4" THEN 30
     WHEN "HwA" THEN 31
     WHEN "AB8" THEN 31
     WHEN "IAA" THEN 32
     WHEN "ACA" THEN 32
     WHEN "IQA" THEN 33
     WHEN "ACE" THEN 33
     WHEN "IgA" THEN 34
     WHEN "ACI" THEN 34
     WHEN "IwA" THEN 35
     WHEN "ACM" THEN 35
     WHEN "JAA" THEN 36
     WHEN "ACQ" THEN 36
     WHEN "JQA" THEN 37
     WHEN "ACU" THEN 37
     WHEN "JgA" THEN 38
     WHEN "ACY" THEN 38
     WHEN "JwA" THEN 39
     WHEN "ACc" THEN 39
     WHEN "KAA" THEN 40
     WHEN "ACg" THEN 40
     WHEN "KQA" THEN 41
     WHEN "ACk" THEN 41
     WHEN "KgA" THEN 42
     WHEN "ACo" THEN 42
     WHEN "KwA" THEN 43
     WHEN "ACs" THEN 43
     WHEN "LAA" THEN 44
     WHEN "ACw" THEN 44
     WHEN "LQA" THEN 45
     WHEN "AC0" THEN 45
     WHEN "LgA" THEN 46
     WHEN "AC4" THEN 46
     WHEN "LwA" THEN 47
     WHEN "AC8" THEN 47
     WHEN "MAA" THEN 48
     WHEN "ADA" THEN 48
     WHEN "MQA" THEN 49
     WHEN "ADE" THEN 49
     WHEN "MgA" THEN 50
     WHEN "ADI" THEN 50
     WHEN "MwA" THEN 51
     WHEN "ADM" THEN 51
     WHEN "NAA" THEN 52
     WHEN "ADQ" THEN 52
     WHEN "NQA" THEN 53
     WHEN "ADU" THEN 53
     WHEN "NgA" THEN 54
     WHEN "ADY" THEN 54
     WHEN "NwA" THEN 55
     WHEN "ADc" THEN 55
     WHEN "OAA" THEN 56
     WHEN "ADg" THEN 56
     WHEN "OQA" THEN 57
     WHEN "ADk" THEN 57
     WHEN "OgA" THEN 58
     WHEN "ADo" THEN 58
     WHEN "OwA" THEN 59
     WHEN "ADs" THEN 59
     WHEN "PAA" THEN 60
     WHEN "ADw" THEN 60
     WHEN "PQA" THEN 61
     WHEN "AD0" THEN 61
     WHEN "PgA" THEN 62
     WHEN "AD4" THEN 62
     WHEN "PwA" THEN 63
     WHEN "AD8" THEN 63
     WHEN "QAA" THEN 64
     WHEN "AEA" THEN 64
     WHEN "QQA" THEN 65
     WHEN "AEE" THEN 65
     WHEN "QgA" THEN 66
     WHEN "AEI" THEN 66
     WHEN "QwA" THEN 67
     WHEN "AEM" THEN 67
     WHEN "RAA" THEN 68
     WHEN "AEQ" THEN 68
     WHEN "RQA" THEN 69
     WHEN "AEU" THEN 69
     WHEN "RgA" THEN 70
     WHEN "AEY" THEN 70
     WHEN "RwA" THEN 71
     WHEN "AEc" THEN 71
     WHEN "SAA" THEN 72
     WHEN "AEg" THEN 72
     WHEN "SQA" THEN 73
     WHEN "AEk" THEN 73
     WHEN "SgA" THEN 74
     WHEN "AEo" THEN 74
     WHEN "SwA" THEN 75
     WHEN "AEs" THEN 75
     WHEN "TAA" THEN 76
     WHEN "AEw" THEN 76
     WHEN "TQA" THEN 77
     WHEN "AE0" THEN 77
     WHEN "TgA" THEN 78
     WHEN "AE4" THEN 78
     WHEN "TwA" THEN 79
     WHEN "AE8" THEN 79
     WHEN "UAA" THEN 80
     WHEN "AFA" THEN 80
     WHEN "UQA" THEN 81
     WHEN "AFE" THEN 81
     WHEN "UgA" THEN 82
     WHEN "AFI" THEN 82
     WHEN "UwA" THEN 83
     WHEN "AFM" THEN 83
     WHEN "VAA" THEN 84
     WHEN "AFQ" THEN 84
     WHEN "VQA" THEN 85
     WHEN "AFU" THEN 85
     WHEN "VgA" THEN 86
     WHEN "AFY" THEN 86
     WHEN "VwA" THEN 87
     WHEN "AFc" THEN 87
     WHEN "WAA" THEN 88
     WHEN "AFg" THEN 88
     WHEN "WQA" THEN 89
     WHEN "AFk" THEN 89
     WHEN "WgA" THEN 90
     WHEN "AFo" THEN 90
     WHEN "WwA" THEN 91
     WHEN "AFs" THEN 91
     WHEN "XAA" THEN 92
     WHEN "AFw" THEN 92
     WHEN "XQA" THEN 93
     WHEN "AF0" THEN 93
     WHEN "XgA" THEN 94
     WHEN "AF4" THEN 94
     WHEN "XwA" THEN 95
     WHEN "AF8" THEN 95
     WHEN "YAA" THEN 96
     WHEN "AGA" THEN 96
     WHEN "YQA" THEN 97
     WHEN "AGE" THEN 97
     WHEN "YgA" THEN 98
     WHEN "AGI" THEN 98
     WHEN "YwA" THEN 99
     WHEN "AGM" THEN 99
     WHEN "ZAA" THEN 100
     WHEN "AGQ" THEN 100
 ELSE
     TRUNC(p.rowid / 0)
 END pdq_value
FROM
 sysprocplan p, sysprocedures f
WHERE
 p.planid = -2 AND
 f.procid = p.procid
ORDER BY 2 DESC

Procedural version:
Versão procedimental:


CREATE FUNCTION get_proc_pdq_value(v_proc_name VARCHAR(128))
RETURNING SMALLINT;

DEFINE v_ret_pdq_value SMALLINT;


SELECT
 f.procname,
 CASE data[1,3]
     WHEN "AAA" THEN 0
     WHEN "AQA" THEN 1
     WHEN "AAE" THEN 1
     WHEN "AgA" THEN 2
     WHEN "AAI" THEN 2
     WHEN "AwA" THEN 3
     WHEN "AAM" THEN 3
     WHEN "BAA" THEN 4
     WHEN "AAQ" THEN 4
     WHEN "BQA" THEN 5
     WHEN "AAU" THEN 5
     WHEN "BgA" THEN 6
     WHEN "AAY" THEN 6
     WHEN "BwA" THEN 7
     WHEN "AAc" THEN 7
     WHEN "CAA" THEN 8
     WHEN "AAg" THEN 8
     WHEN "CQA" THEN 9
     WHEN "AAk" THEN 9
     WHEN "CgA" THEN 10
     WHEN "AAo" THEN 10
     WHEN "CwA" THEN 11
     WHEN "AAs" THEN 11
     WHEN "DAA" THEN 12
     WHEN "AAw" THEN 12
     WHEN "DQA" THEN 13
     WHEN "AA0" THEN 13
     WHEN "DgA" THEN 14
     WHEN "AA4" THEN 14
     WHEN "DwA" THEN 15
     WHEN "AA8" THEN 15
     WHEN "EAA" THEN 16
     WHEN "ABA" THEN 16
     WHEN "EQA" THEN 17
     WHEN "ABE" THEN 17
     WHEN "EgA" THEN 18
     WHEN "ABI" THEN 18
     WHEN "EwA" THEN 19
     WHEN "ABM" THEN 19
     WHEN "FAA" THEN 20
     WHEN "ABQ" THEN 20
     WHEN "FQA" THEN 21
     WHEN "ABU" THEN 21
     WHEN "FgA" THEN 22
     WHEN "ABY" THEN 22
     WHEN "FwA" THEN 23
     WHEN "ABc" THEN 23
     WHEN "GAA" THEN 24
     WHEN "ABg" THEN 24
     WHEN "GQA" THEN 25
     WHEN "ABk" THEN 25
     WHEN "GgA" THEN 26
     WHEN "ABo" THEN 26
     WHEN "GwA" THEN 27
     WHEN "ABs" THEN 27
     WHEN "HAA" THEN 28
     WHEN "ABw" THEN 28
     WHEN "HQA" THEN 29
     WHEN "AB0" THEN 29
     WHEN "HgA" THEN 30
     WHEN "AB4" THEN 30
     WHEN "HwA" THEN 31
     WHEN "AB8" THEN 31
     WHEN "IAA" THEN 32
     WHEN "ACA" THEN 32
     WHEN "IQA" THEN 33
     WHEN "ACE" THEN 33
     WHEN "IgA" THEN 34
     WHEN "ACI" THEN 34
     WHEN "IwA" THEN 35
     WHEN "ACM" THEN 35
     WHEN "JAA" THEN 36
     WHEN "ACQ" THEN 36
     WHEN "JQA" THEN 37
     WHEN "ACU" THEN 37
     WHEN "JgA" THEN 38
     WHEN "ACY" THEN 38
     WHEN "JwA" THEN 39
     WHEN "ACc" THEN 39
     WHEN "KAA" THEN 40
     WHEN "ACg" THEN 40
     WHEN "KQA" THEN 41
     WHEN "ACk" THEN 41
     WHEN "KgA" THEN 42
     WHEN "ACo" THEN 42
     WHEN "KwA" THEN 43
     WHEN "ACs" THEN 43
     WHEN "LAA" THEN 44
     WHEN "ACw" THEN 44
     WHEN "LQA" THEN 45
     WHEN "AC0" THEN 45
     WHEN "LgA" THEN 46
     WHEN "AC4" THEN 46
     WHEN "LwA" THEN 47
     WHEN "AC8" THEN 47
     WHEN "MAA" THEN 48
     WHEN "ADA" THEN 48
     WHEN "MQA" THEN 49
     WHEN "ADE" THEN 49
     WHEN "MgA" THEN 50
     WHEN "ADI" THEN 50
     WHEN "MwA" THEN 51
     WHEN "ADM" THEN 51
     WHEN "NAA" THEN 52
     WHEN "ADQ" THEN 52
     WHEN "NQA" THEN 53
     WHEN "ADU" THEN 53
     WHEN "NgA" THEN 54
     WHEN "ADY" THEN 54
     WHEN "NwA" THEN 55
     WHEN "ADc" THEN 55
     WHEN "OAA" THEN 56
     WHEN "ADg" THEN 56
     WHEN "OQA" THEN 57
     WHEN "ADk" THEN 57
     WHEN "OgA" THEN 58
     WHEN "ADo" THEN 58
     WHEN "OwA" THEN 59
     WHEN "ADs" THEN 59
     WHEN "PAA" THEN 60
     WHEN "ADw" THEN 60
     WHEN "PQA" THEN 61
     WHEN "AD0" THEN 61
     WHEN "PgA" THEN 62
     WHEN "AD4" THEN 62
     WHEN "PwA" THEN 63
     WHEN "AD8" THEN 63
     WHEN "QAA" THEN 64
     WHEN "AEA" THEN 64
     WHEN "QQA" THEN 65
     WHEN "AEE" THEN 65
     WHEN "QgA" THEN 66
     WHEN "AEI" THEN 66
     WHEN "QwA" THEN 67
     WHEN "AEM" THEN 67
     WHEN "RAA" THEN 68
     WHEN "AEQ" THEN 68
     WHEN "RQA" THEN 69
     WHEN "AEU" THEN 69
     WHEN "RgA" THEN 70
     WHEN "AEY" THEN 70
     WHEN "RwA" THEN 71
     WHEN "AEc" THEN 71
     WHEN "SAA" THEN 72
     WHEN "AEg" THEN 72
     WHEN "SQA" THEN 73
     WHEN "AEk" THEN 73
     WHEN "SgA" THEN 74
     WHEN "AEo" THEN 74
     WHEN "SwA" THEN 75
     WHEN "AEs" THEN 75
     WHEN "TAA" THEN 76
     WHEN "AEw" THEN 76
     WHEN "TQA" THEN 77
     WHEN "AE0" THEN 77
     WHEN "TgA" THEN 78
     WHEN "AE4" THEN 78
     WHEN "TwA" THEN 79
     WHEN "AE8" THEN 79
     WHEN "UAA" THEN 80
     WHEN "AFA" THEN 80
     WHEN "UQA" THEN 81
     WHEN "AFE" THEN 81
     WHEN "UgA" THEN 82
     WHEN "AFI" THEN 82
     WHEN "UwA" THEN 83
     WHEN "AFM" THEN 83
     WHEN "VAA" THEN 84
     WHEN "AFQ" THEN 84
     WHEN "VQA" THEN 85
     WHEN "AFU" THEN 85
     WHEN "VgA" THEN 86
     WHEN "AFY" THEN 86
     WHEN "VwA" THEN 87
     WHEN "AFc" THEN 87
     WHEN "WAA" THEN 88
     WHEN "AFg" THEN 88
     WHEN "WQA" THEN 89
     WHEN "AFk" THEN 89
     WHEN "WgA" THEN 90
     WHEN "AFo" THEN 90
     WHEN "WwA" THEN 91
     WHEN "AFs" THEN 91
     WHEN "XAA" THEN 92
     WHEN "AFw" THEN 92
     WHEN "XQA" THEN 93
     WHEN "AF0" THEN 93
     WHEN "XgA" THEN 94
     WHEN "AF4" THEN 94
     WHEN "XwA" THEN 95
     WHEN "AF8" THEN 95
     WHEN "YAA" THEN 96
     WHEN "AGA" THEN 96
     WHEN "YQA" THEN 97
     WHEN "AGE" THEN 97
     WHEN "YgA" THEN 98
     WHEN "AGI" THEN 98
     WHEN "YwA" THEN 99
     WHEN "AGM" THEN 99
     WHEN "ZAA" THEN 100
     WHEN "AGQ" THEN 100
 ELSE
     -1
 END pdq_value
INTO
 v_ret_pdq_value
FROM
 sysprocplan p, sysprocedures f
WHERE
 p.planid = -2 AND
 f.procid = p.procid AND
 f.procname = v_proc_name;

IF v_ret_pdq_value = -1
THEN
 RAISE EXCEPTION -746,0,'Could not decode PDQ value. Please check query';
ELSE
 RETURN v_ret_pdq_value;
END IF
END FUNCTION;

Updated on Jan 12, 2011: Cosmo noted that the procedure should be declared as a function and asked me to reference him as Cosmo instead of Simon David

Alterado em 12 de Jan de 2011: O Cosmo referiu que o procedimento deveria ser declarado como função e pediu para ser referido como Cosmo em vez de Simon David

New French Blog / Novo blog em Francês

2010-12-16T23:18:00.003Z

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English Version:

It's a great pleasure to present you another Informix blog. This one is written in French. The author is Eric Vercelletto, which was a colleague at Informix Portugal. Eric has a long history with Informix. We was working at Informix France and decided to join Informix Portugal mainly to participate in a big and complex project several years ago (before I joined Informix). After that we met and worked together on another customer. At the time I was working mainly with tools and he managed all the engine side stuff. When he decided to embrace other challenges outside Informix, I assumed his position at that customer. It was a big challenge for me (I had relatively low experience with the engine) and Eric was a great help. I still use some of his scripts today, and I learned many things with him.
But the world never stops spinning and currently Eric is back on Informix, and he's enthusiastic about it. I wish him all the best and I really hope he is able to share some of his knowledge about Informix with the community.
He decided to write the blog in French since French people like to take care of their language. This is great news for the French community. As for us, non French speaking people we can try our best to understand it. It would be interesting to see it in English also... (just a challenge Eric ;) ). But for now, the important it to keep a steady rate of articles. And I can assure you it's hard. Welcome Eric!

The blog address is:

http://levillageinformix.blogspot.com/

(something like "the Informix village")

Versão Portuguesa:

É um grande prazer poder apresentar-vos um novo blog Informix. Desta feita escrito em Francês. O autor é Eric Vercelletto, que foi um colega da Informix Portugal. O Eric tem um longo passado com Informix. Estava a trabalhar na Informix França e decidiu juntar-se à Informix Portugal, pricipalmente para participar num projecto grande e complexo há vários anos atrás (antes de eu ingressar na Informix Portugal). Após isso conhecemo-nos e trabalhámos juntos num outro cliente. Na altura eu trabalhava essencialmente com ferramentas e ele geria o lado do motor.
Quando ele decidiu abraçar outros desafios fora da Informix, assumi a sua posição no cliente. Foi um grande desafio para mim (tinha muito pouca experiência com o motor) e o Eric foi uma grande ajuda. Ainda utilizo alguns dos seus scripts hoje, e aprendi muitas coisas com ele.
Mas o mundo dá voltas e mais voltas e actualmente o Eric está de volta ao Informix, e continua entusiasta. Desejo-lhe tudo de bom e espero sinceramente que ele consiga partilhar algum do seu conhecimento Informix com a comunidade.
Ele decidiu escrever o blog em Francês porque os Franceses gostam de cuidar da sua língua. Isto são excelentes notícias para a comunidade Francófona. Quanto a nós, que não dominamos a língua, tentaremos o nosso melhor para o perceber. Era interessante ver o conteúdo também em Inglês (só um desafio Eric... :) ). Mas por agora, o importante é manter um ritmo constante de novos artigos. E posso assegurar que não é fácl. Bem vindo Eric!

O endereço do blog é:

http://levillageinformix.blogspot.com/

(algo como "a aldeia do Informix", o que vindo da Gália, trás boas recordações de criança)

Informix ROI webcast

2010-12-16T00:15:00.004Z

This article is written in English and Portuguese
Este artigo está escrito em Português e Inglês

English version:

Following the recent announcement of a Forrester study about Informix ROI, a webcast was held on December 13. The replay can be seen here:

https://www.techwebonlineevents.com/ars/eventregistration.do?mode=eventreg&F=1002717&K=4ON

You can listen to it in webcast format and also download the slides and sound file.
The presentation was done by Jon Erickson from Forrester and Richard Wozniak who browses through some of the Panther key features.
Be sure to pass this to your company management!

Versão Portuguesa:

No seguimento do recente anúncio sobre um estudo da Forrester sobre o ROI (return on investment) do Informix, foi apresentado um webcast no dia 13 de Dezembro. Pode rever esta apresentação aqui:

https://www.techwebonlineevents.com/ars/eventregistration.do?mode=eventreg&F=1002717&K=4ON

Pode ouvir/ver em formato webcast e também fazer o download dos ficheiros com os slides e o som.
A apresentação foi feita por Jon Erickson da Forrester e Richard Wozniak que abordou algumas das principais funcionalidades da versão Panther (11.7)
Não deixe de divulgar esta informação aos gestores da sua organização!