Informix technology

V15: Obtain the query plan of a running query

2024-11-27T23:30:00.009+00:00

New feature that allows retrieving a query plan of a running query (original version here)

English version
For anyone involved with RDBMS, the concept of a query plan and its importance is not new. Most performance issues are probably related to bad query plans. So, the ability to obtain the query plan of a query is a base stone of the DBA work. And informix allows it for as long as I can remember. The only "slight" issue is that it only works for a query that we run or simulate to run. Why is this an issue? For three main reasons:

It's an hassle to have to capture a query and it's parameters (if the query is prepared), run it in a tool and obtain the query plan. Specially for short lived queries
The fact that a prepared query may have a different query plan than the one we get in a tool with a query written with values (more on this later)
A long running query may be using a different query plan than the one we get, because some of the conditions may be different (update statistics may have been run, parameters or context may have changed)

So, we could overcome the first point with some work, but we cannot overcome the last points. And in order to understand what is happening with a running query we MUST be able to capture the existing plan of a query that is being run. This is why it was so difficult for me to understand why it took so long to fix this. The only explanation I have is an enormous "distance" between developers and people who use the products. This is not exclusive to Informix. I've personally felt this with other products.
This is just to explain that this was a "since ever" requested feature. I personally officially registered it at

https://ideas.ibm.com/ideas/INFX-I-249

on April 2013. But this was not the first time I pushed for it. I even made some attempts do dig into the memory structures that would show this, but the lack of internal documentation made it a nightmare and a dead end. Anyway, enough with the history. The feature was implemented in version 15, and for me personally this would be the top priority. Let's see how we can use it. There are two interfaces to access the query plan:

onstat -g qplan <0 | session_id>
query the sysmaster:syssqexplain

Let's start by opening a session an run a simple query:

SELECT * FROM customer WHERE customer_num > 110;

On another session let's identify the session and run the onstat command on that session:


asterix@myhost.onlinedomus.local:informix-> onstat -g qplan 91

IBM Informix Dynamic Server Version 15.0.0.0AEE -- On-Line -- Up 2 days 00:23:07 -- 2193704 Kbytes
2024-11-25 22:34:02 -- Infrastructure Version: 1

Session [91]
QUERY:
------
SELECT * FROM customer WHERE customer_num > 110

QUERY: (OPTIMIZATION TIMESTAMP: 11-25-2024 22:34:03)Estimated Cost: 3
Estimated # of Rows Returned: 18

  1) informix.customer: INDEX PATH

    (1) Index Name: informix. 100_1
        Index Keys: customer_num   (Serial, fragments: ALL)
        Lower Index Filter: informix.customer.customer_num > 110



asterix@myhost.onlinedomus.local:informix->

Very simple. If a session has no active query (or if we issue the command too late) we'll get:


asterix@myhost.onlinedomus.local:informix-> onstat -g qplan 91

IBM Informix Dynamic Server Version 15.0.0.0AEE -- On-Line -- Up 2 days 00:25:14 -- 2193704 Kbytes
2024-11-25 22:36:10 -- Infrastructure Version: 1

Session [91]: No running query to generate the plan.

asterix@myhost.onlinedomus.local:informix->

Again very simple. Now let's check how this can be done through SQL The feature introduced a new column on the sysmaster:syssqexplain, called sqx_sqlstatementplan. So we simply need to query this with a filter on sqx_session_id. An example:


asterix@myhost.onlinedomus.local:informix-> dbaccess -e sysmaster qplan.sql

Database selected.

SELECT
        sqx_sqlstatementplan
FROM
        sysmaster:syssqexplain
WHERE
        sqx_sessionid = 91



sqx_sqlstatementp+
                    QUERY: (OPTIMIZATION TIMESTAMP: 11-25-2024 22:41:12)Estimat
                    ed Cost: 3
                    Estimated # of Rows Returned: 18

                      1) stores:informix.customer: INDEX PATH

                        (1) Index Name: informix. 100_1
                            Index Keys: customer_num   (Serial, fragments: ALL)

                            Lower Index Filter: stores:informix.customer.custom
                    er_num > 110


1 row(s) retrieved.


Database closed.

asterix@myhost.onlinedomus.local:informix->

Before I end this article, I'd like to get back to point 2) above. The fact that a prepared statement may have a different query plan from what we can reproduce by writing the same statement and using the same values as in it's parameters. This is usually hard to explain to customers who usually don't understand why I don't trust in the query plan obtained in dbaccess when we're trying to analyze a performance issue where prepared statements are involved. The reason why this happens is one of the main reasons why this feature is so important, so I think it's worth the effort to dive a bit into this subject. The first important thing we need to clarify is what is a prepared statement? A prepared statement is a statement sent to the engine with the conditions in the WHERE clause, but where the values used in those conditions CAN be replaced by questions marks. If we wanted to prepared the statement above used as an example, the query text would be: SELECT * FROM customer WHERE customer_num > ?
When the statement is prepared, it is sent to the engine, and the engine validates the syntax. The statement executions will pass the parameters. On the first execution, the engine will calculate the query plan. And this is the crucial point around this discussion. The plan will depend on the first execution values, and in normal circumstances will not change until the statement is re-prepared or re-optimized. I'll try to show this with an example, created in JAVA. Let's start with a snippet of the program code:


1   import java.sql.*;
2   import java.util.*;
3   import java.text.*;
4   import com.informix.jdbc.*;
5   import java.util.Scanner;
6
7
8   public class cursor_iter
9   {
10      public static void main( String [] args ) {
11
12              Connection conn = null;
13              int count=0;
14              ResultSet dbRes = null;
15              IfxStatement is = null;
16              Statement is1 = null;
17              String timeStamp;
18              SimpleDateFormat dateFormat;
19              com.informix.jdbc.IfmxPreparedStatement ps = null;
20              Statement st = null;
21              Scanner scan = new Scanner(System.in);
22
23              try {
24
25                      Class.forName("com.informix.jdbc.IfxDriver");
26                      conn = DriverManager.getConnection("jdbc:informix-sqli://myhost:10010/example_db:INFORMIXSERVER=goscinny;USER=informix;PASSWORD=MASKEDPWD;");
27
28              } catch (Exception sqle1) {
29                      System.out.println("Database connection has failed.");
30                      System.out.println("Reason: " + sqle1.getMessage());
31              }
32
33
34
35              try {
36                      st = conn.createStatement();
37                      st.executeUpdate("SET EXPLAIN ON");
38
39                      ps = (com.informix.jdbc.IfmxPreparedStatement) conn.prepareStatement("SELECT * FROM example_table WHERE id >= ?");
40                      System.out.println("STEP 1: Statement prepared. Press ENTER to set parameter\n");scan.nextLine();
41
42                      ps.setInt(1, 1);
43                      System.out.println("STEP 2: Parameter set to 1. Press ENTER to execute\n");scan.nextLine();
44                      ResultSet rs = ps.executeQuery();
45                      System.out.println("STEP 3: Query executed with 1. Press ENTER to position in result set\n");scan.nextLine();
46                      rs.next();
47                      System.out.println("STEP 4: Next() executed with 1. Value: " + rs.getString(1) + ". Press ENTER to close result set\n");scan.nextLine();
48                      rs.close();
49                      System.out.println("STEP 5: ResultSet closed. Press ENTER to set parameter\n");scan.nextLine();
50
51                      ps.setInt(1, 2);
52                      System.out.println("STEP 6: Parameter set to 2. Press ENTER to execute query\n");scan.nextLine();
53                      rs = ps.executeQuery();
54                      System.out.println("STEP 7: Query executed with 2. Press ENTER to position in result set\n");scan.nextLine();
55                      rs.next();
56                      System.out.println("STEP 8: Next() executed with 2. Value: " + rs.getString(1) + ". Press ENTER to close result set\n");scan.nextLine();
57                      rs.close();
58                      System.out.println("STEP 9: ResultSet closed. Press ENTER to set parameter\n");scan.nextLine();
59
60                      ps.setInt(1, 7);
61                      System.out.println("STEP 10: Parameter set to 7. Press ENTER to execute with reoptimization\n");scan.nextLine();
62                      rs = ps.executeQuery(false,true);
63                      System.out.println("STEP 11: Query executed with 7 with re-optimization. Press ENTER to position in result set\n");scan.nextLine();
64                      rs.next();
65                      System.out.println("STEP 12: Next() executed with 7. Value: " + rs.getString(1) + ". Press ENTER to close\n");scan.nextLine();
66                      rs.close();
67                      System.out.println("STEP 13: ResultSet closed. Press ENTER to set parameter\n");scan.nextLine();
68
69                      ps.setInt(1, 1);
70                      System.out.println("STEP 14: Parameter set to 1. Press ENTER to execute query\n");scan.nextLine();
71                      rs = ps.executeQuery();
72                      System.out.println("STEP 15: Query executed with 1. Press ENTER to position in result set\n");scan.nextLine();
73                      rs.next();
74                      System.out.println("STEP 16: Next() executed with 1. Value: " + rs.getString(1) + ". Press ENTER to close result set\n");scan.nextLine();
75                      rs.close();
76                      System.out.println("STEP 17: ResultSet closed. Press ENTER to finish\n");scan.nextLine();
77              } catch (SQLException sqle) {

The code is fairly simple (disclaimer: it may contain some errors or bad practices). The list of actions is:

Lines 23-31: It connects to the DB
Lines 36,37: Activates the explain
Line 39: Prepares a statement with one host variable
Lines 42-49: Sets the host variable to "1" and executes the query, fetches a row and closes the result set
Lines 51-58: Repeats the execution for value "2"
Lines 60-67: Repeats the execution for value "7", but with re-optimization
Lines 69-76: Repeats the execution for value 1 again

Each step will wait for user input. The purpose of the code is to show the following:

The first query plan calculation happens on the first execution and the plan uses a sequencial scan (because the query has a filter >= 1 and "1" is the lowest table value, so statistically the query will return the whole table
The second execution does not recalculate the plan
The third execution uses a very selective value (7), and is executed with the option to re-optimize the plan. And because we have a different value (with much higher selectivity) it will choose an index
The last execution doesn't request re-optimization, and although it uses the first value (1) it will use the index

Hopefully when you analyze the behavior you'll understand:

Prepared statements calculate the query plan for the value(s) passed in the first execution, unless we request a re-optimization (which will recalculate the plan and from then on) this one will be used until a new re-optimization is requested
New simple execution will re-use the latest calculated plan
A plan calculated once can be good for certain values and bad for others. Prepared statements don't care about this
This "issue" is only meaningful if for a certain plan you have values that are good and others that would benefit from a different plan. In other words, if your table distribution is not relatively uniform across values
Most important conclusion: Given the previous points it should become clear why the need for this feature should be so obvious for anyone using Informix.

To make it a bit more clear why we get two different plans here is the column distributions:


goscinny@myhost.onlinedomus.local:informix-> dbschema -d example_db -hd example_table | head -33

DBSCHEMA Schema Utility       INFORMIX-SQL Version 12.10.FC15

{

Distribution for idt.example_table.id
Constructed on 2024-10-19 01:13:30.77780
High Mode, 0.500000 Resolution

--- DISTRIBUTION ---
    (                                   1)
 1: (        10,          1,            7)

--- OVERFLOW ---

 1: (  16670876,                        1)
 2: (  16664127,                        2)
 3: (  16659895,                        3)
 4: (  16664556,                        4)
 5: (  16670374,                        5)
 6: (  16670185,                        6)

goscinny@myhost.onlinedomus.local:informix->

So, the values 1,2,3,4,5 and 6 are considered overflows meaning they have many rows (~16.6M each). Value 7 has only 10 rows. So, if we start the executions with value 1, it will choose a sequential scan which is the best option because we're expecting to read the whole table. But once we have that query plan, an execution with "7" would take a long time (which is why I used "2" in the second execution).
On the other hand, if we use "7" on the first execution, the engine chooses the index path, which again is the best option for this value, but would not be a good option for "1" (and most probably the others).

This is the nature of prepared statements with tables with uneven distributions. The workarounds for these cases are not in the scope for this article (it could be a good idea to cover this in another article), but I hope this makes it very clear why we need to get the effective plan of a running query and not a plan we get on dbaccess by writing the query with values.

And here is video capture of the above code. On the left side you can see what is being written to the sqexplain.out file where it becomes evident when the query plans are calculated and re-used. On the right side there's the code running and pausing for user input.

One final note: When we re-optimize we seem to get a "phantom" execution of the query with the previous plan and the new value. If you check it, you'll see the statistics of the execution are equal to the last one used (for value 2). I believe this is a glitch or bug in the SET EXPLAIN code. A sequential scan for value 7 would take a long time to return (I tested it). And it would not return the same stats as for the value 2

Here's the video to make this more clear:

Versão Portuguesa

Para qualquer pessoa envolvida com RDBMS, o conceito de plano de execução e a sua importância não será novidade. A maioria dos problemas de performance estão provavelmente relacionados com maus planos de execução. Assim, a capacidade de obter um plano de execução de uma query, é como uma pedra de fundação do trabalho de DBA. E o Informix permite isso desde que me recordo. O único "ligeiro" problema é que isso só funciona para uma query que vamos executar ou simular a execução. Porque é que isto é um problema? Por três razões principais:

É trabalhoso ter de obter uma query e os seus parâmetros (se a query fôr "PREPAREd"), executá-la numa ferramenta e daí obter o plano se execução. Em especial se a query fôr de curta duração
O facto de que uma query "PREPAREd" pode ter um plano de execução diferente daquele que obtemos correndo a query directamente com valores numa ferramenta (mais sobre isto mais adiante)
Uma query com uma execução muito longa, pode estar a usar um plano de execução diferente daquele que obtemos, porque as condições podem ter-se alterado (as estatísticas podem ter sido refeitas, parâmetros ou contexto pode ser diferente...)

Portanto, podemos contornar ou ignorar o primeiro ponto, com mais ou menos trabalho, mas não conseguimos resolver os últimos pontos. E para entendermos o que se passa com uma query em execução TEMOS mesmo de ser capazes de capturar o seu efectivo plano de execução. É por isto que sempre me foi muito difícil entender porque demorou tanto tempo a corrigir isto. A única explicação que encontro é uma grande "distância" entre quem desenvolve e quem usa os produtos. Isto não se passa apenas no Informix. Tenho-o sentido com outros produtos também.
Serve tudo isto para explicar que esta funcionalidade era um pedido "desde sempre". Registei-o oficialmente aqui

https://ideas.ibm.com/ideas/INFX-I-249

em Abril de 2013. Mas este não foi o primeiro momento em que batalhei por isto. Cheguei mesmo a fazer algumas tentativas para vasculhar estruturas de memória que poderiam conter esta informação. Mas a falta de documentação sobre essas estruturas tornou a tarefa num pesadelo e beco sem saída.

Bom, mas chega de história. A funcionalidade foi implementada na versão 15, e para mim sempre seria uma prioridade absoluta. Vejamos como a podemos utilizar. Existem duas interfaces para aceder ao plano de execução:

onstat -g qplan <0 | id_sessao>
consultar a sysmaster:syssqexplain

Comecemos por abrir uma sessão e executar uma query simples::

SELECT * FROM customer WHERE customer_num > 110;

Noutra sessão vamos identificar a sessão de base de dados onde a query está a correr e executar o comando onstat contra essa sessão:


asterix@myhost.onlinedomus.local:informix-> onstat -g qplan 91

IBM Informix Dynamic Server Version 15.0.0.0AEE -- On-Line -- Up 2 days 00:23:07 -- 2193704 Kbytes
2024-11-25 22:34:02 -- Infrastructure Version: 1

Session [91]
QUERY:
------
SELECT * FROM customer WHERE customer_num > 110

QUERY: (OPTIMIZATION TIMESTAMP: 11-25-2024 22:34:03)Estimated Cost: 3
Estimated # of Rows Returned: 18

  1) informix.customer: INDEX PATH

    (1) Index Name: informix. 100_1
        Index Keys: customer_num   (Serial, fragments: ALL)
        Lower Index Filter: informix.customer.customer_num > 110



asterix@myhost.onlinedomus.local:informix->

Muito simples. Se a sessão não tiver nenhuma query activa (ou se dermos o comando demasiado tarde) é isto que obtemos:


asterix@myhost.onlinedomus.local:informix-> onstat -g qplan 91

IBM Informix Dynamic Server Version 15.0.0.0AEE -- On-Line -- Up 2 days 00:25:14 -- 2193704 Kbytes
2024-11-25 22:36:10 -- Infrastructure Version: 1

Session [91]: No running query to generate the plan.

asterix@myhost.onlinedomus.local:informix->

Novamente muito simples. Agora vejamos como podemos aceder a esta informação via SQL. A funcionalidade introduziu uma nova coluna na sysmaster:syssqexplain, chamada sqx_sqlstatementplan. Portanto só temos de interrogar esta view seleccionando esta coluna e filtrando pela coluna sqx_session_id. Um exemplo:


asterix@myhost.onlinedomus.local:informix-> dbaccess -e sysmaster qplan.sql

Database selected.

SELECT
        sqx_sqlstatementplan
FROM
        sysmaster:syssqexplain
WHERE
        sqx_sessionid = 91



sqx_sqlstatementp+
                    QUERY: (OPTIMIZATION TIMESTAMP: 11-25-2024 22:41:12)Estimat
                    ed Cost: 3
                    Estimated # of Rows Returned: 18

                      1) stores:informix.customer: INDEX PATH

                        (1) Index Name: informix. 100_1
                            Index Keys: customer_num   (Serial, fragments: ALL)

                            Lower Index Filter: stores:informix.customer.custom
                    er_num > 110


1 row(s) retrieved.


Database closed.

asterix@myhost.onlinedomus.local:informix->

Antes de terminar este artigo, gostaria de voltar ao ponto 2) acima. É um facto que uma query PREPAREd pode usar um plano de execução diferente do que conseguimos reproduzir, usando o mesmo SQL e parâmetros. É habitual ter alguma dificuldade em explicar isto a clientes, que geralmente não entendem porque não confio nos planos de execução obtidos por exemplo no dbaccess, quando tentamos analisar problemas de performance que envolvam este tipo de instruções.

A razão porque isto acontece é uma das principais razões porque esta funcionalidade é tão importante, e assim penso que vale o esforço de aprofundar mais o tema. Temos de começar por clarificar o que é uma instrução "PREPAREd". É uma instrução enviada ao motor de base de dados, em que os valores das condições da cláusula WHERE podem ser substituídos por pontos de interrogação. Caso quiséssemos fazer o PREPARE do exemplo acima usaríamos: SELECT * FROM customer WHERE customer_num > ?

Quando a instrução é "PREPAREd", é enviada ao motor, e o motor irá validá-la sintacticamente. Depois as várias execuções da instrução irão passar parâmetros. Na primeira execução o motor irá calcular o plano de execução. E este é o ponto crucial para a discussão. O plano irá depender dos valores passados para a primeira execução, e em circunstâncias normais não irá mudar até que a instrução seja novamente PREPAREd ou re-optimizada. Vou tentar evidenciar isto com um exemplo, criado em JAVA. Comecemos por ver um excerto desse programa:


1   import java.sql.*;
2   import java.util.*;
3   import java.text.*;
4   import com.informix.jdbc.*;
5   import java.util.Scanner;
6
7
8   public class cursor_iter
9   {
10      public static void main( String [] args ) {
11
12              Connection conn = null;
13              int count=0;
14              ResultSet dbRes = null;
15              IfxStatement is = null;
16              Statement is1 = null;
17              String timeStamp;
18              SimpleDateFormat dateFormat;
19              com.informix.jdbc.IfmxPreparedStatement ps = null;
20              Statement st = null;
21              Scanner scan = new Scanner(System.in);
22
23              try {
24
25                      Class.forName("com.informix.jdbc.IfxDriver");
26                      conn = DriverManager.getConnection("jdbc:informix-sqli://myhost:10010/example_db:INFORMIXSERVER=goscinny;USER=informix;PASSWORD=MASKEDPWD;");
27
28              } catch (Exception sqle1) {
29                      System.out.println("Database connection has failed.");
30                      System.out.println("Reason: " + sqle1.getMessage());
31              }
32
33
34
35              try {
36                      st = conn.createStatement();
37                      st.executeUpdate("SET EXPLAIN ON");
38
39                      ps = (com.informix.jdbc.IfmxPreparedStatement) conn.prepareStatement("SELECT * FROM example_table WHERE id >= ?");
40                      System.out.println("STEP 1: Statement prepared. Press ENTER to set parameter\n");scan.nextLine();
41
42                      ps.setInt(1, 1);
43                      System.out.println("STEP 2: Parameter set to 1. Press ENTER to execute\n");scan.nextLine();
44                      ResultSet rs = ps.executeQuery();
45                      System.out.println("STEP 3: Query executed with 1. Press ENTER to position in result set\n");scan.nextLine();
46                      rs.next();
47                      System.out.println("STEP 4: Next() executed with 1. Value: " + rs.getString(1) + ". Press ENTER to close result set\n");scan.nextLine();
48                      rs.close();
49                      System.out.println("STEP 5: ResultSet closed. Press ENTER to set parameter\n");scan.nextLine();
50
51                      ps.setInt(1, 2);
52                      System.out.println("STEP 6: Parameter set to 2. Press ENTER to execute query\n");scan.nextLine();
53                      rs = ps.executeQuery();
54                      System.out.println("STEP 7: Query executed with 2. Press ENTER to position in result set\n");scan.nextLine();
55                      rs.next();
56                      System.out.println("STEP 8: Next() executed with 2. Value: " + rs.getString(1) + ". Press ENTER to close result set\n");scan.nextLine();
57                      rs.close();
58                      System.out.println("STEP 9: ResultSet closed. Press ENTER to set parameter\n");scan.nextLine();
59
60                      ps.setInt(1, 7);
61                      System.out.println("STEP 10: Parameter set to 7. Press ENTER to execute with reoptimization\n");scan.nextLine();
62                      rs = ps.executeQuery(false,true);
63                      System.out.println("STEP 11: Query executed with 7 with re-optimization. Press ENTER to position in result set\n");scan.nextLine();
64                      rs.next();
65                      System.out.println("STEP 12: Next() executed with 7. Value: " + rs.getString(1) + ". Press ENTER to close\n");scan.nextLine();
66                      rs.close();
67                      System.out.println("STEP 13: ResultSet closed. Press ENTER to set parameter\n");scan.nextLine();
68
69                      ps.setInt(1, 1);
70                      System.out.println("STEP 14: Parameter set to 1. Press ENTER to execute query\n");scan.nextLine();
71                      rs = ps.executeQuery();
72                      System.out.println("STEP 15: Query executed with 1. Press ENTER to position in result set\n");scan.nextLine();
73                      rs.next();
74                      System.out.println("STEP 16: Next() executed with 1. Value: " + rs.getString(1) + ". Press ENTER to close result set\n");scan.nextLine();
75                      rs.close();
76                      System.out.println("STEP 17: ResultSet closed. Press ENTER to finish\n");scan.nextLine();
77              } catch (SQLException sqle) {

O código é bastante simples (salvaguarda: o código pode conter erros ou más práticas). A lista de acções é:

Linhas 23-31: Abre a conexão à BD
Linhas 36,37: Activa a escrita do plano de execução para ficheiro
Linhas 39: Faz o PREPARE com uma variável "host"
Linhas 42-49: Define a variável "host" a "1", executa a query, posiciona-se numa linha e fecha o "result set"
Linhas 51-58: Repete a execução para o valor "2"
Linhas 60-67: Repete a execução para o valor "7", mas desta feita com re-optimização
Linhas 69-76: Repete a execução para o valor "1" novamente

Em cada passo espera pelo input do utilizador. Os objectivos deste código são mostrar o seguinte:

O cálculo do primeiro plano de execução acontece na primeira execução, e usa uma busca sequencial na tabela (pois tem um filtro ">= 1" e "1" é o menor valor da tabela, portanto estatisticamente deveremos ler a tabela toda)
A segunda execução não recalcula o plano
A terceira execução usa um valor muito selectivo (7), e é efectuada com a opção de re-optimização. Sendo um valor muito mais selectivo o plano vai escolher acesso por índice
A última execução não pede re-optimização, e embora use o primeiro valor (1) que despoletou um acesso sequencial vai usar o plano com acesso por índice calculado na interação anterior.

Espero que depois de analisado este comportamento possa entender o seguinte:

Instruções PREPAREd calculam o plano para o(s) valor(es) passado(s) na primeira execução, e a menos que seja pedida uma re-optimização (que irá recalcular o plano a usar daí em diante), irá usar sempre o mesmo plano calculado na primeira execução.
Novas execuções "simples" irão utilizar o último plano calculado
Um plano calculado uma vez pode ser bom para certos valores e mau para outros. Instruções PRERAREd trabalham mesmo assim
Este "problema" só tem impacto se para determinado plano há valores "bons" e outros "maus". Por outras palavras, só tem impacto quando a tabela tem distribuições não uniformes entre os diferentes valores possíveis.
A conclusão mais importante: Dados os pontos anteriores, deverá estar muito claro para quem usa Informix porque necessitamos tanto desta nova funcionalidade.

Para tornar o exemplo um pouco mais claro, e explicar porque obtemos diferentes planos, aqui fica a distribuição de valores na coluna usada na cndição:


goscinny@myhost.onlinedomus.local:informix-> dbschema -d example_db -hd example_table | head -33

DBSCHEMA Schema Utility       INFORMIX-SQL Version 12.10.FC15

{

Distribution for idt.example_table.id
Constructed on 2024-10-19 01:13:30.77780
High Mode, 0.500000 Resolution

--- DISTRIBUTION ---
    (                                   1)
 1: (        10,          1,            7)

--- OVERFLOW ---

 1: (  16670876,                        1)
 2: (  16664127,                        2)
 3: (  16659895,                        3)
 4: (  16664556,                        4)
 5: (  16670374,                        5)
 6: (  16670185,                        6)

goscinny@myhost.onlinedomus.local:informix->

Portanto, os valores 1,2,3,4,5 e 6 são considerados "overflows", o que significa que têm muitas linhas (~16.6M cada). O valor 7 só tem 10 linhas. Assim se iniciamos as execuções com o valor "1", irá escolher uma busca sequencial, dado que espera ler toda a tabela, e assim é o método mais eficiente. Mas uma vez que tenhamos esse plano, uma execução para o valor "7" demoraria muito tempo (daí ter usado "2" na segunda execução). Por outro lado, se usamos o "7" na primeira execução ficaremos com um plano de acesso por índice, pois é a melhor opção para este valor. Mas não será a melhor opção para o valor "1" (e provavelmente para os outros).

Esta é a natureza das instruções PREPAREd com tabelas com distribuições "irregulares". As formas de contornar estes casos não estão no âmbito deste artigo (poderia ser uma boa ideia fazer um artigo dedicado ao tema), mas espero que isto torne claro porque necessitamos mesmo de conseguir obter o plano efectivo de uma query em execução, e não o plano que é gerado pela query escrita com os valores.

E abaixo está uma captura de video da execução do código explicado acima. Do lado esquerdo pode seguir o que vai sendo escrito no ficheiro de saída do SET EXPLAIN. o que evidencia quando é que os planos são calculados e re-utilizados. Do lado direito tem a execução do código com as pausas para input do utilizador.

Uma nota final: Quando se efectua a re-optimização, aparentemente obtemos uma execução "fantasma" da query com o plano anterior e o valor novo. Se atentar nos dados, verá que as estatísticas e execução são iguais às mostradas no passo anterior (para o valor "2"). Suponho que isto seja um bug do SET EXPLAIN. Uma pesquisa sequencial para o valor "7" demoraria muito mais tempo a retornar (eu tentei). E naturalmente não retornaria as mesmas estatísticas que foram retornadas pelo valor "2".

Aqui fica o vídeo:

Heads up!

2024-11-25T23:30:00.001+00:00

Warning: old tools with new version (original version here)

English version
In the post about the release of version 15 I've mentioned an heads up about the risk of using the new version of the engine with current versions of the tools (4GL/ISQL). I hope I can show the issue more clearly here while we start to grasp on the expanded capacity of version 15.

Version 15 has two "modes" of operation. The "compatibility mode" or "Infrastructure Version: 0" and the new version "Infrastructure Version: 1". Currently I have no idea if future changes will create new modes.

In "Compatibility Mode" the engine cannot create "LARGE TABLEs". If you try to use the "CREATE LARGE TABLE tabname...." you'll get:

   261: Cannot create table (informix.test_large).
 21568: V1 infrastructure features have not yet been enabled.

The mode is shown for example if you run "onstat -":

IBM Informix Dynamic Server Version 15.0.0.0AEE -- On-Line -- Up 00:21:11 -- 222740 Kbytes
2024-11-24 02:28:09 -- Infrastructure Version: 0 (Compatibility mode)

There is a process to "convert" an instance from Infrastructure Version 0 to 1, but I won't cover that in this post. Let's now see what happens in an instance created from scratch in version 15. By default all tables will be in "LARGE TABLE" mode. But we have the option to create "SMALL TABLEs". A way to check if a table is in LARGE or SMALL mode is by running oncheck:

asterix@myhost.onlinedomus.local-> oncheck -pt stores:customer | head -10


TBLspace Report for stores:informix.customer

    Physical Address               8:566
    Creation date                  11/19/2024 15:31:46
    TBLspace Flags                 400000802        Row Locking
                                                    TBLspace uses 4 bit bit-maps
                                                    TBLspace uses large rowids
    Maximum row size               134
asterix@myhost.onlinedomus.local->

Note the "TBLspace uses large rowids" section. Let's create a small table and check it:

asterix@myhost.onlinedomus.local-> dbaccess -e stores small_test.sql

Database selected.

DROP TABLE IF EXISTS customer_small;
Table dropped.


CREATE SMALL TABLE customer_small
(
    customer_num SERIAL NOT NULL ,
    fname CHAR(15),
    lname CHAR(15),
    company CHAR(20),
    address1 CHAR(20),
    address2 CHAR(20),
    city CHAR(15),
    state CHAR(2),
    zipcode CHAR(5),
    phone CHAR(18),
    PRIMARY KEY (customer_num)
) LOCK MODE ROW;
Table created.



INSERT INTO customer_small SELECT * FROM customer;
28 row(s) inserted.




Database closed.

asterix@myhost.onlinedomus.local->

So now if we check the customer_small table:

asterix@myhost.onlinedomus.local-> oncheck -pt stores:customer_small | head -10


TBLspace Report for stores:informix.customer_small

    Physical Address               8:662
    Creation date                  11/24/2024 02:47:29

    TBLspace Flags                 802              Row Locking
                                                    TBLspace uses 4 bit bit-maps
    Maximum row size               134
    Number of special columns      0
asterix@myhost.onlinedomus.local->

There is no indication of "large rowids" so it's a "small" table. Now let's see what happens if we try to use ISQL on these two tables. I'm using 7.51.FC3, currently the latest available version of the tools.

As you can see the form works as expected for "customer_small" table, but raises an error for "customer" table. Let's check the error with the tools environment:

asterix@myhost.onlinedomus.loca-> finderr -21569
Message number -21569 not found.
 
asterix@myhost.onlinedomus.loca:informix->

The error is unknown. Not a surprise as the error didn't exist when this version of the tools was created. So let's check it in the engine environment:

  
  asterix@myhost.onlinedomus.local:informix-> . setinfx 5
Welcome to CDC Instance (ADM) Asterix
asterix@myhost.onlinedomus.local:informix-> finderr -21569
-21569  This client cannot create or open tables that use large rowids.

You are attempting to create or open a large table, but your client program
is not compatible with large tables. Set the TABLE_SIZE session environment
variable to "SMALL" or rebuild your client using the latest client libraries.


asterix@myhost.onlinedomus.local:informix->

So, it makes sense. The engine understands the application is expecting small rowids and raises an error if the table was created with LARGE mode.

This is the risk you face if you try to use the engine in version 15 before a new version of the tools are released. Note that this will affect any application that relies or handles rowids. The problem will not manifest if you upgrade an instance and avoid changing it to the new Infrastructure Mode, or in other words, while you keep in Compatibility Mode.
At the time of this writing I am unaware of any method to force the Infrastructure Version 0 on a newly created instance. This would mean that any environment that depends on rowids would require a tools refresh before any upgrade is considered. Don't take this lightly or you'll risk serious issues on your applications. An alternative would be (in a newly created instance) to create all the tables as SMLL

Let it be clear that there is an environment option to change the default type of tables we wish to create (when we don't specify the SMALL nor the LARGE option). That option is set with the command:

SET ENVIRONMENT TABLE_SIZE <SMALL|LARGE>

Note that if you try to set it to "LARGE" in an instance running in compatibility mode you'll get the error:

mouraria@psygnosis.onlinedomus.local:informix-> finderr -26041
-26041  Invalid values specified for the %s environment variable.

An invalid value was provided for the environment variable. Please check
your user documentation, and provide the correct value, and try again.

Versão Portuguesa
No artigo sobre a disponibilização da versão 15, mencionei um aviso sobre o risco de usar a nova versão do motor com as versões actuais das ferramentas (4GL/ISQL). Espero agora poder mostrar aqui de forma mais clara este tema, enquanto começamos a entrar mais na capacidade estendida da versão 15

A versão 15 tem dois "modos" de operação. O modo de compatibilidade ou "Infrastructure Version 0" e o novo modo ou "Infrastructure Version 1". De momento não faço ideia se futuras alterações poderão dar origem a outros modos.

Em modo de compatibilidade o motor não pode criar "LARGE TABLEs". Se tentarmos usar "CREATE LARGE TABLE nom_tabela...." obteremos:

   261: Cannot create table (informix.test_large).
 21568: V1 infrastructure features have not yet been enabled.

O modo pode ser mostrado quando executamos "onstat -":

IBM Informix Dynamic Server Version 15.0.0.0AEE -- On-Line -- Up 00:21:11 -- 222740 Kbytes
2024-11-24 02:28:09 -- Infrastructure Version: 0 (Compatibility mode)

Existe um processo para "converter" uma instância do modo "Infrastructure Version 0" para "Infrastructure Version 1", mas não vou cobrir isso neste artigo. Vejamos agora o que acontece numa instância criada de raiz na versão 15. Por omissão todas as tabelas serão "LARGE TABLES". Mas temos a opção de criar "SMALL TABLEs". Uma forma de verificar o tipo de tabela é usar o comando oncheck:

asterix@myhost.onlinedomus.local-> oncheck -pt stores:customer | head -10


TBLspace Report for stores:informix.customer

    Physical Address               8:566
    Creation date                  11/19/2024 15:31:46
    TBLspace Flags                 400000802        Row Locking
                                                    TBLspace uses 4 bit bit-maps
                                                    TBLspace uses large rowids
    Maximum row size               134
asterix@myhost.onlinedomus.local->

Repare-se na secção "TBLspace uses large rowids". Vamos criar uma SMALL TABLE e verificar:

asterix@myhost.onlinedomus.local-> dbaccess -e stores small_test.sql

Database selected.

DROP TABLE IF EXISTS customer_small;
Table dropped.


CREATE SMALL TABLE customer_small
(
    customer_num SERIAL NOT NULL ,
    fname CHAR(15),
    lname CHAR(15),
    company CHAR(20),
    address1 CHAR(20),
    address2 CHAR(20),
    city CHAR(15),
    state CHAR(2),
    zipcode CHAR(5),
    phone CHAR(18),
    PRIMARY KEY (customer_num)
) LOCK MODE ROW;
Table created.



INSERT INTO customer_small SELECT * FROM customer;
28 row(s) inserted.




Database closed.

asterix@myhost.onlinedomus.local->

Verifiquemos então a tabela customer_small:

asterix@myhost.onlinedomus.local-> oncheck -pt stores:customer_small | head -10


TBLspace Report for stores:informix.customer_small

    Physical Address               8:662
    Creation date                  11/24/2024 02:47:29

    TBLspace Flags                 802              Row Locking
                                                    TBLspace uses 4 bit bit-maps
    Maximum row size               134
    Number of special columns      0
asterix@myhost.onlinedomus.local->

Não há referência a "large rowids" portanto é uma "SMALL TABLE". Agora vejamos o que acontece se tentarmos usar o ISQL com ambas as tabelas. Vou usar a versão 7.51.FC3, actualmente a última versão disponível das ferramentas.

Como se verifica, o "form" funciona normalmente para a tabela "customer_small", mas retorna um erro para a tabela "customer". Vamos verificar o erro com o ambiente das ferramentas:

asterix@myhost.onlinedomus.loca-> finderr -21569
Message number -21569 not found.
 
asterix@myhost.onlinedomus.loca:informix->

O erro é desconhecido. Não é uma surpresa visto que o erro não existia quando esta versão das ferramentas foi criada. Verifiquemos então no ambiente do motor:

  
  asterix@myhost.onlinedomus.local:informix-> . setinfx 5
Welcome to CDC Instance (ADM) Asterix
asterix@myhost.onlinedomus.local:informix-> finderr -21569
-21569  This client cannot create or open tables that use large rowids.

You are attempting to create or open a large table, but your client program
is not compatible with large tables. Set the TABLE_SIZE session environment
variable to "SMALL" or rebuild your client using the latest client libraries.


asterix@myhost.onlinedomus.local:informix->

Portanto tudo faz sentido. O motor entende que a aplicação está à espera de rowids "curtos" e cria um erro se a tabela em causa foi criada como LARGE TABLE.

Este é o risco que enfrentamos se usarmos a versão 15 do motor antes da disponibilização de novas versões das ferramentas. Note-se que isto afectará qualquer aplicação que dependa ou manipule rowids. O problema não se manifesta se fizermos upgrade a uma instância e evitarmos mudar o "Infrastructure Mode", ou por outras palavras, enquanto a mantivermos em modo de compatibilidade.

à data de escrita deste artigo desconheço se há alguma forma de forçar o modo de compatibilidade numa instância criada de raiz na versão 15. Isto significa que qualquer upgrade para a versão 15 com recriação de instância requererá uma nova versão das tools. Não menospreze este tema pois haverá sérios riscos de as aplicações deixarem de funcionar. Uma alternativa seria (numa instância criada de raiz) criar todas as tabelas como SMALL.

Note-se que há uma opção de ambiente para mudar o tipo de tabela a criar por omissão (quando não se usa o SMALL ou o LARGE no CREATE TABLE).
Essa opção é usar o comando:

SET ENVIRONMENT TABLE_SIZE <SMALL|LARGE>

Refira-se ainda que, uma tentativa de estabelecer esta opção como LARGE, numa instância que se encontre em modo de compatibilidade gerará um erro:

mouraria@psygnosis.onlinedomus.local:informix-> finderr -26041
-26041  Invalid values specified for the %s environment variable.

An invalid value was provided for the environment variable. Please check
your user documentation, and provide the correct value, and try again.

Informix version 15 is GA

2024-11-22T03:21:00.002+00:00

Informix version 15 is GA! (original version here)

English version
Version 15 of Informix was officially released and is generally available in the usual places!
I'll try to cover the new functionalities here in the upcoming weeks in some detail. For now I just want to mention the overall impression and a list of new features with brief comments. On the overall feeling, I'd say it's very good, although not perfect... But it really depends on our expectations and main concerns. When we see a new major version we all hope that all our required and more dearest features are there. And it never happens. And then there are the new features we didn't expect. In this particular case we had some public sessions where some points were disclosed so some of what is there was to be expected. A few things mentioned before were left out. So the surprise factor was not that high since that public session, but if we go before that, and someone asked me if I'd expect major physical changes in the internal structures of the engine I would clearly say: "no way". But our amazing developers did it! Eventually these big changes forced a few others to be left out, and that's why I say it's not perfect. But by changing these things now they're laying the foundations to future improvements. I cannot go through this without recalling the question I heard constantly around 2001 when IBM bought Informix: "What's the future of the product?". I always answered "honestly I don't think anyone can be sure, but it's being developed". And 23 years later (yes, 23!) we're seeing major architectural changes! So this is overall the feeling I have. Now let's see a brief list of new features and some comments:

Java: Engine does not include a JRE environment. And Java version 11 is needed (Informix HQ and Java UDRs for example)
GSKit updated to version 8.0.60.1
The "real thing": The internal limits were changed. This means that a lot of limits that we're used to are now much higher. So high that it looks like there is no limits. I'd say none of us will have to worry about limits during our career. But we've seen many examples in the past where people assured similar things and then it turned out as big failed previsions. Let me quote the new limits from the fine manual:

A single table fragment/partition can have 140 trillion pages
A chunk may be as large as 8 exabytes (this is the unit after Petabyte which is above Terabyte. So an exabyte would be 1024x1024 Terabytes. Yes.... a very large number)
Data rows per page depends on pagesize but can reach 29122 in 256KB pages (maximum was 255 independently of page size)
Page size can be 2, 4 ,8, 16, 32, 64, 128 and 256 KBytess (maximum was 32)
Data rows per fragment/partition is 9.2 quintillion

There would be much more to say about limits. I'd say for now that the table/disk structures for now don't have "real" limits. The limits that can still have some impact would be things like number of user threads, row size (32KBytes) and a few other that were not changed at this phase. I'll get back to the limits in the end of this post for an important heads up!

External smart blobs: Smart blobs can now be stored in external filesystems. This can have a huge impact in terms of backups. A tradicional smart blobspace has to exist to store the smart blobs metadata

Invisible indexes, is a new functionality that allows a DBA to set an index to "invisible". An invisible index will be maintained as a normal index (for INSERTs, UPDATEs and DELETEs) but will not be used by queries. This allows a DBA to "test" a system behavior as if the index did not exist, and revert easily and immediately if the result is not good. An index can also be created in "invisible mode" and turned visible later.
I would expect some functionality to change a session to allow the use of invisible indexes for that session only. That would allow a DBA to test the use of an index before really turning it on for all the sessions. BUT NOTE THIS IS JUST A PERSONAL IDEA: THERE IS NO SUGGESTION THAT THIS FEATURE WILL BE IMPLEMENTED IN THE FUTURE
Obtain query plan of a running query. This one could have put tears in my eyes... I need this most of the times I have a performance issue to solve. I think an image speaks louder than a thousand words, so let me just show this:

Yes... I opened this feature 11 years ago.

Improved audit records analysis. This means the Session ID (SID) can appear in the audit logs. Since I mentioned images, let me show another one:

Yes... I opened this feature 9 years ago. And before that I had many internal discussions to try to push this. The argument was simple: The information is nearly useless without this because just by using the client process ID means that in many cases we cannot correlate the actions shown in the log. The argument against was always the dreadful "we cannot make the outputs incompatible with previous behavior". Check!

Replication update: changes to '--cascade replicate'. The --cascade replicate option is now generally available for replicates, also through templates. A replicate having the --cascaderepl option turned on will be able, on its only sending participant, to pick up transaction traffic arriving through other replicates. This used to be available only for SPL replication situations
Informix HQ 3.0

Automatic account lockout after 5 invalid access attempts
Support for "LARGE TABLES". We can create LARGE TABLEs and see if a table is categorized as SMALL or LARGE table. A future article will dive into what is a LARGE table. For now let's just assume it's a table with expanded capacity
Droping constraints directly from the user interface
Multiple servers refresh simultaneously

CDC API support on secondary servers. I've been using InfoSphere Change Data Capture (InfoSphere CDC) very much lately, which uses the Informix CDC API. Being able to take advantage of secondary servers will be great news for Informix customers who use CDC to send data to other systems.
New version format. Not exactly a new functionality, but something we all need to get used to. Traditionally Informix versions had the format M.R.xyz.Extra where:

M.R was the major release (11.50, 11.70, 12.10, 14.10)
x was the platform indication (F for 64 bit, U for 32 bit and T for Windows)
y was the type of release (B for Beta, C for initial release, D for later release with significant changes)
z was the fixpack number
Extra was a mark for specific fixes like "X1"

Now it will use: M.R.m.f-Extra where:

M is the major version
R is the release version
m is the "modification" identifier (a modpack includes changes)
f is the fixpack (a fixpack should include fixes)
Extra is an identifier for special builds

Client SDK and JDBC versions will match the server version (avoids a lot of confusion)

Heads up!

I mentioned before I'd go back to the limits for an important heads up. And I think this is really important. The new limits are implemented among others with a major change to what we know as "RowID". A row ID in "traditional" informix structure was a four byte value, divided into two components: 3 bytes of "page address" (thus the limit of around 16M pages in a fragment/partition) and 1 byte for a slot table pointer (thus the limit of 255 rows per page). New "expanded" RowIDs should be able to use 8 bytes. Traditional tools like 4GL and ISQL have some functionality that depends on RowIDs. So, existing versions will not be able to use the new extended RowIDs. If you check the compatibility page (https://www.ibm.com/support/pages/node/502131) you'll see the 7.51.FC3 tools version is certified for Informix V15.0.0.0, BUT only for "small table mode". I don't want to get into details in this generic post, but if you upgrade an existing instance to V15, you'll be in "compatible mode" and the extended capacity is not available. If you change it to "infrastructure version 1" or if you create an instance from scratch you'll be in "new version mode" and the expanded capacity will be available. Existing tools will not work 100% in this case so you must be very careful on the steps you take. A new version of the tools is being worked on but at the time of this writing there is no ETA for it. I was assured this is a priority and the development team is working on it.

Versão Portuguesa

A versão 15 do Informix foi oficialmente lançada e está disponível nos sítios habituais!

Vou tentar cobrir as novas funcionalidades na próximas semanas com algum detalhe. Por agora apenas pretendo expor a impressão geral e uma lista de funcionalidades com uns breves comentários. Relativamente à impressão geral é bastante boa, mas não perfeita... Mas isto depende das nossas expectativas e principais preocupações. Quando vemos uma nova versão todos sonhamos que todos os nossos desejos de funcionalidades tenham sido implementados. E isto nunca acontece. E depois existem as funcionalidades que não esperávamos. Neste caso em particular, nós tivemos umas sessões públicas onde alguns pontos foram divulgados, portanto uma boa parte do que foi implementado já era esperado. Algumas das coisas discutidas anteriormente não foram implementadas. Mas digamos que não houve um grande factor surpresa desde essa sessão pública. Mas se recuarmos ao ponto no tempo antes da sessão, e me tivessem perguntado se eu esperava grandes mudanças na organização física dos dados (estruturas internas do motor), a minha resposta seria: "Nem pensar!". Mas a "nossa" extraordinária equipa de desenvolvimento fê-lo! Eventualmente o esforço para implementar estas mudanças obrigou a deixar de fora outras funcionalidades discutidas publicamente e por isso digo que a sensação não é perfeita.
Mas ao implementar estas mudanças agora, o desenvolvimento está a estabelecer bases para futuras alterações e melhoria. Não consigo deixar de me lembrar da pergunta que ouvia frequentemente por volta de 2001, quando a IBM adquiriu a Informix: "Qual é o futuro do produto?". Eu respondia sempre: "Honestamente penso que ninguém pode afirmar com certeza, mas continua a ser desenvolvido". E 23 anos depois (sim, 23!) estamos a assistir a grandes mudanças estruturais! Portanto esta é a sensação que tenho. Vejamos agora uma lista de novas funcionalidades e alguns comentários sobre as mesmas:

Java: O motor deixa de incluir um JRE. E a versão Java necessária é a 11 (Informix HQ e Java UDRs por exemplo)
GSKit actualizado para a versão 8.0.60.1
A grande mudança: Os limites internos foram mudados. Isto significa que muitos dos limites a que nos habituámos estão agora muito maiores. Tão maiores que dão a sensação que deixou de haver limites. Diria que nenhum de nós terá de se preocupar com limites durante a nossa carreira. Mas já vimos muitas personalidades ilustres fazerem este tipo de afirmação e depois revela-se que foram apenas previsões falhadas. Deixem-me citar alguns limites a partir do manual:

Um único fragmento/partição de uma tabela pode ter 140 triliões de páginas
Um chink pode atingir 8 exabytes (isto é a unidade acima do Petabyte que está acima do Terabyte. Portanto um exabyte serão 1024x1024 Terabytes. Sim.... um número muito grande)
Número de linhas por página depende do tamanho da página mas pode chegar às 29122 em páginas de 256KB (o máximo era 255 independentemente do tamanho da página)
Os tamanhos de página podem ser 2, 4 ,8, 16, 32, 64, 128 e 256 KBytess (o máximo era 32)
Linhas por fragmento/partição é de 9.2 quintiliões

Haveria muito mais para dizer sobre os limites. Direi por agora que as estruturas de tabelas/disco não têm limites "reais". Os limites que poderão ainda ter algum impacto serão coisas como o número de threads de utilizador, tamanho de linha (32Kbytes) e alguns outros que não foram mudados nesta fase. Voltarei ao tema dos limites no final deste artigo para um alerta importante

Smart Blobs externos: Os Smart blobs podem agora ser armazenados em sistemas de ficheiros. Isto pode ter um enorme impacto no backups. Um smart blobspace tradicional terá se existir para guardar a metadata dos smart blobs

Indices invisíveis é uma nova funcionalidade que permite ao DBA tornar um índice "invisível". Um índice invisível será mantido como um índice normal (para INSERTs, UPDATEs e DELETEs) mas não será usado em queries. Assim um DBA poderá testar o comportamento do sistema como se o índice não existisse, e reverter fácil e rapidamente caso o resultado não seja bom. Um índice pode também ser criado em "modo invisível" e tornado visível mais tarde.
Eu esperaria que houvesse uma funcionalidade a nível de sessão que permita o uso de índices marcados como invisíveis para a sessão apenas. Isto auxiliaria um DBA a testar o uso de um índice antes que o torne "público" para todas as sessões. MAS NOTE_SE QUE ISTO É APENAS UMA IDEIA PESSOAL. NÃO HÀ QUALQUER SUGESTÃO QUE TAL FUNCIONALIDADE VENHA A SER IMPLEMENTADA NO FUTURO
Obter o plano de execução de uma query que esteja a correr. Com esta podia facilmente verter umas lágrimas... Necessito disto na maioria das vezes que observo algum problema de performance. Mas penso que uma imagem vale mais que mil palavras, portanto deixem-me só partilhar isto:

Sim... Abri este pedido de melhoria há 11 anos atrás.

Melhoria na análise dos registos de auditing. Isto significa que a identificação da sessão pode aparecer nos logs de auditing. Já que falamos de imagens deixem-me partilhar mais uma:

Sim.... Abri esta funcionalidade há 9 anos atrás. E antes disso tive várias discussões internas para tentar promover isto. O argumento era simples: A informação guardada (sem ID de sessão) era virtualmente inútil, pois usando apenas o ID do processo cliente não permitia correlacionar as operações auditadas. O contra-argumento era sempre o drástico "não podemos mudar os outputs para formatos incompatíveis com versões anteriores". Check!

Alterações na replicação: mudanças na opção '--cascade replicate'. Esta opção está agora genericamente disponível para replicates, e também através de templates. Um replicate com esta opção activada, poderá, no seu único participante marcado como sender, replicar dados que cheguem de outros replicates. Isto só estava disponível para replicação por SPL
Informix HQ 3.0

Bloqueio automático de contas ao fim de 5 tentativas de acesso falhadas
Suporte para "LARGE TABLES". Podemos criar LARGE TABLEs e ver se uma tabela está caracterizada como SMALL ou LARGE. Um próximo artigo aprodunará o tema das LARGE TABLEs. Por agora vamos apenas assumir que uma LARGE TABLE é uma tabela com capacidade expandida
Eliminar constraints directamente pelo GUI
Refrescamento de vários servidores em simultâneo

Suporte à API de CDC API nos servidores secundários.Tenho usado o InfoSphere Change Data Capture (InfoSphere CDC) muito ultimamente, um produto que usa a Informix CDC API. Poder tirar proveito dos servidores secundários para este fim é uma excelente notícia para os clientes Informix que usam o CDC para enviar dados para outros sistemas.
Novo formato da versão. Não é exactamente uma nova funcionalidade, mas sim algo a que teremos de nos habituar. Tradicionalmente o Informix usava o formato M.R.xyz.Extra onde:

M.R era a major release (11.50, 11.70, 12.10, 14.10)
x era o indicativo de plataforma (F para 64 bits, U para 32 bits e T para Windows)
y era o tipo da release (B para Beta, C para release inicial, D para releases posteriores com mudanças significativas)
z era o número do fixpack
Extra era a marca para fixes específicos como "X1"

Agora utilizará: M.R.m.f-Extra onde:

M é a major version
R é a release version
m é o indicador de "modificação" (um modpack incluirá mudanças)
f é o fixpack (um fixpack deverá incluir apenas correcções)
Extra é um identificador para special builds

O Client SDK e o JDBC seguirão as versões do motor (evita muitas confusões)

Aviso!

Mencionei acima que voltaria aos limites para um aviso importante. E parece-me verdadeiramente importante. Os novos limites foram implementados entre outras mudanças pela mudança completa do que conhecemos como "RowID". Um row ID na estrutura tradicional do Informix é uma estrutura com quatro bytes dividido em dois componentes: 3 bytes para o endereço de página (daí o limite de cerca de 16M de páginas por fragmento/partição) e 1 byte para um ponteiro na slot table (daí o limite de 255 linhas por página). Os novos RowIDs "expandidos" poderão usar 8 bytes. As ferramentas tradicionais como o 4GL e o ISQL têm algumas funcionalidades que dependem do RowID. Portanto as versões existentes não serão capazes de usar os RowIDs expandidos. Se verificar a página de compatibilidade (https://www.ibm.com/support/pages/node/502131) verifica que a versão 7.51.FC3 das ferramentas está certificada para Informix V15.0.0.0, MAS só para "small table mode". Não quero entrar em demasiados detalhes neste artigo genérico, mas quando fazemos upgrade a uma instância já existente para a versão 15, estaremos em "modo de compatibilidade" e a capacidade estendida não estará disponível. Se mudarmos para "versão 1 da infira-estrutura", ou se criarmos uma instância nova na V15 estaremos então em "modo de versão nova" e a capacidade estendida estará disponível. As ferramentas existentes não funcionarão a 100% neste caso e portanto é muito importante ter cuidado com os passos que damos. Uma nova versão das ferramentas está a ser desenvolvida, mas à data da escrita deste artigo não existe uma data de disponibilização definida. Foi-me assegurado que isto é uma prioridade e que a equipa de desenvolvimento está a trabalhar nisto

2024-11-19T14:59:00.003+00:00

InformixV15 is Out: onstat -

IBM Informix Dynamic Server Version 15.0.0.0AEE -- On-Line -- Up 00:11:43 -- 20241119 Kbytes
2024-11-19 14:52:08 -- Infrastructure Version: 1

InformixV15 is Out:

👏😉💪

Changes in support plans /Mudanças nos planos de suporte

2024-03-12T09:11:00.001+00:00

Changes in support plans (original version here)

English version
IBM has made public some changes in support plans. You can read it directly here:
https://www.ibm.com/support/pages/node/7114112

In a very short summary it announces that the existing Continuing Support Program will terminate on April 30, 2025. This program would allow customers with versions that already entered "End of Support" period to open support tickets. The tickets would be accepted and worked on as long as they wouldn't require code analysis or bug fixes. It had no costs except the normal "service and support" costs.
On the other side it announces that the new IBM Extended Support program will be available for Informix. This program allows full support, including bug fixes, for a period of four years after normal end of support. It has an associated cost.

This change may force some customers to rethink their upgrade strategy (or to create one...). The change is controversial for sure. Some will say this is a way for IBM to get more money. As an IBMer my opinion is obviously biased. What I can say is that in my experience and perspective, it's not usual for customers to pay for extended support and I feel that allowing customers to continue using old version harms the product. It is constantly compared with other technologies, and that comparison becomes unfair when you compare an old version of Informix with the new features from competitors.

Versão Portuguesa

A IBM anunciou mudanças nos planos de suporte. Pode ler directamente aqui:
https://www.ibm.com/support/pages/node/7114112

Muito resumidamente a nota informa que o programa de "Continuing Support" terminará em 30 de Abril de 2025. Este programa permitia que clientes que usassem versões que já tivessem entrado na fase de "End of Support" pudessem abrir casos no suporte. Esses casos seriam aceites e a IBM trabalharia neles, desde que não necessitassem de análise de código ou correcção de bugs. O programa não tinha custos adicionais excepto o normal "Service and Support".

Em contrapartida anuncia-se também que o novo "IBM Extended Support Program" estará disponível para Informix. Este programa disponibiliza suporte total, incluindo correccção de bugs, por um período de quatro anos após a data "normal" de fim de suporte. Este programa tem um custo associado.

Esta mudança irá forçar alguns clientes a repensar a sua estratégia de upgrade (ou a criar uma). A mudança é certamente controversa. Alguns dirão que é uma forma de a IBM ganhar mais dinheiro. Como IBMer a minha opinião é obviamente enviesada. O que posso dizer, baseado na minha experiência e perspectiva, é que não é habitual os clientes pagarem por suporte estendido, e que sinto que permitir aos clientes continuarem a usar versões muito antigas prejudica o produto. Estamos constantemente a ser comparados com outras tecnologias, e essa comparação torna-se injusta quando comparamos versões antigas do Informix com as novas funcionalidades dos competidores.

Rethinking AUTO_REPREPARE

2024-03-01T12:49:00.002+00:00

Revisiting AUTO_REPREPARE parameter (original version here)

English version
A recent customer engagement made me analyze the use of this parameter. I have no absolute certain, but what it seems is that the system starts to use a non-optimal query plan (the reason for this is not yet clear, but seems related to the way statistics are updated) for a specific query. The query can be seen running very frequently and taking much longer than it should and the CPU consumption increases. Running statistics doesn't seem to help, but restarting the applications does solve the issue.

A possible explanation is that the query is PREPAREd, and the query plan doesn't change even when we run the statistics. Eventually new sessions will get the correct query plan, and the system returns to normal. This is (up to a point) a normal effect when using prepared statements. Obviously this is highly inconvenient.

That's where the AUTO_REPREPARE parameter can play a fundamental role. This parameter was introduced to avoid the error -710. This used to happen when a table used in a PREPARED statement was changed (new indexes, new columns, dropping columns etc.). The next occurrences of the execution would raise this error and would require an explicit re-preparation of the query, a re-opening of the associated cursor or another activity that would force the calculation of a new plan.

The parameter exists since version 11.10 but it only accepted two values: 0 to turn the feature off and 1 to turn it off. In version 12.10 new values were introduced but apparently they didn't get enough visibility:

0 = Disables the automatic repreparation of prepared objects after the schema of a directly or an indirectly referenced table is modified. Also disables the automatic reoptimization of SPL routines after the schema of an indirectly referenced table is modified.
1 = Enables automatic repreparation.
3 = Enables automatic repreparation in optimistic mode.
5 = Enables automatic repreparation on update statistics.
7 = Enables automatic repreparation in optimistic mode and on update statistics

As we can see, there are options that will trigger automatic statement re-preparation on UPDATE STATISTICS (I'll address the "optimistic mode" later). 5 should be exactly what we want. It will take care of schema changes and also when we UPDATE STATISTICS on the tables used. This way the existing (bad) plans will be updated automatically and we avoid the need to restart the applications. The process will be transparent to the applications.

I've created a simple test to show the effect of this setting. I picked up the "demo1.ec" sample from a Client SDK installation and made some changes to it:

Added a variable "customer_num" and a "count" to obtain the number of full scans executed on the table.
Changed the query WHERE condition to use "WHERE customer_num > ?". Also changed the query to use a table "customer_tst" which will be created for the test purpose.
Repeated the cursor block. I want to execute the query three times. First with value 1 (when plan is calculated it uses a sequential scan), then with value 115 (will choose an INDEX path if the plan is recalculated) and a last time with the original value of 1.
Added a SET EXPLAIN ON that will give us an overview of what's happening
Execute UPDATE STATISTICS LOW after first query execution to see if it triggers the re-optimization of the statement
Find out how many sequential scans were run on the test table and return it as return code of the program

I also created a test SHELL script that will do the following steps for different values of AUTO_REPREPARE (1 and 5):

Create a copy of the customer table in the stores demo database (includes data and the index on the customer_num column
Launch the demo_tst compiled program and obtain the return code (number of sequential scans executed on the table)
Show the explain output for the demo_tst program

The code is at the end of this article, if you want to run the test. To run it follow this steps:

Compile the demo_tst program with: esql -o demo_tst demo_tst.ec
Execute the shell script with: ./test.sh

Hopefully what you'll see is:

For execution with AUTO_REPREPARE set to 1:

You will get three sequential scans and the explain plan will show only one plan and three similar executions.

For execution with AUTO_REPREPARE set to 5:

You will get one sequential scan (triggered by the use of "1" in the first query) and two INDEX path (triggered by the use of "115" on the second query, re-optimized because between first and second execution we run UPDATE STATISTICS). Third execution, although it uses the same value as the first execution will follow the plan calculated on the second execution, because there is nothing that triggers the re-optimization between second and third executions.

Conclusion

The (not so) new value of 5 allows PREPARED queries to be re-optimized when statistics on the underlying table(s) are refreshed, allowing the queries to benefit from improved query plans without restarting. It will also avoid the -710 error as the usual value of "1" permits.

Note that sometimes customers don't have AUTO_REPREPARE explicitly set to one, but it assumes this value if AUTO_TUNE is set to 1. However to benefit from this extended improvement we need to explicitly set the value to 5.

The value 3 and 7 are similar respectively to values 1 and 5, but the system will not check for schema changes or UPDATE STATISTICS if a query run successfully in the last second. This will of course open the possibility of getting -710 errors if a query is constantly used.

One question pop out: Is there any reason to run Informix with a different value?

Versão Portuguesa
Uma actividade num cliente fez-me revisitar o uso deste parâmetro (AUTO_REPREPARE). De momento não tenho a certeza absoluta, mas parece que ocasionalmente o sistema começa a usar um plano de execução pior para uma query (a razão para isto ainda não é conhecida mas suspeita-se que está relacionado com a forma como se executam as estatísticas). Nestas alturas a query pode facilmente encontrar-se a correr e demora muito mais que o esperado, e o consumo de CPU aumenta. Recalcular as estatísticas não parece resolver, mas um re-inicio das aplicações faz desaparecer o problema.

Uma possível explicação é que a query está "preparada", e assim o plano não se altera quando executamos o UPDATE STATISTICS. Eventualmente novas sessões obtêm o novo e melhorado plano de execução, e depois o sistema volta ao normal. Isto é (até certo ponto) um efeito esperado da utilização de statements preparados. Obviamente é também bastante inconveniente.

É aqui que o parâmetro AUTO_REPREPARE pode ter um papel fundamental. Este parâmetro foi introduzido para evitar o erro -710. Isto acontecia quando uma tabela usada numa instrução preparada sofria alguma modificação (novos índices, novas colunas, remoção de colunas etc.). A execução seguinte da instrução geraria o erro e seria necessário uma nova abertura de cursor associado, a execução do PREPARE novamente ou outra acção que despoletasse a geração de um novo plano de execução.

Este parâmetro existe desde a versão 11.10, mas só aceitava dois valores: 0 para desligar a funcionalidade e 1 para a ligar. Na versão 12.10 foram introduzidos novos valores, mas aparentemente não tiveram visibilidade suficiente:

0 = Desactiva a "repreparação" automática depois de a estrutura de uma tabela directa ou indirectamente usada na query ser mudada. Desliga também a re-optimizção automática para procedimentos SPL.
1 = Activa a re-optimização automática.
3 = Activa a re-optimização automática em modo "optimista".
5 = Activa a re-optimização automática também para UPDATE STATISTICS.
7 = Activa a re-optimização automática também para UPDATE STATISTICS em modo "optimista".

Como se pode verificar há opções para despoletar a re-optimização das instruções quando ocorre um UPDATE STATISTICS (vermos o modo "optimista" depois). O valor 5 será exactamente o que se pretende. Endereça as alterações de estrutura bem como a execução de estatísticas nas tabelas envolvidas. Desta forma os planos existentes (não óptimos) serão actualizados automaticamente e evitamos o re-inicio das aplicações. Este processo é transparente para as aplicações.

Para demonstrar isto criei um teste simples que permite ver o efeito da funcionalidade. Parti do exemplo "demo1.ec" existente numa instalação de Client SDK e fiz-lhe algumas alterações:

Adicionei uma variável "customer_num" para a condição da query e uma "count" para obter o número de sequential scans efectuados.
Mofifiquei a condição WHERE da query para usar "WHERE customer_num > ?". Também alterei a query para usar uma tabela "customer_tst" que será criada para este propósito.
Repeti o bloco de código que abre o cursor. Quero executar a query três vezes. A primeira será com o valor 1 (o motor escolhe um sequential scan para este valor). Depois com o valor 115 (o plano terá um acesso por índice quando recalculado) e novamente com o valor inicial de 1.
Adicionei um SET EXPLAIN ON que nos dará visibilidade sobre o que se passou.
Execução de um UPDATE STATISTICS LOW depois da primeira execução para vermos de dispara a re-optimização na segunda execução
Obter o número de sequential scans executados na tabela de teste. Esse valor é usado como retorno do programa para que o script possa obter a contagem

Criei também um SHELL script que fará os seguintes passos para ambos os valores do AUTO_REPREPARE (1 e 5):

Cria uma cópia da tabela "customer" na base de dados de demonstração stores (incluí dados e o índice na coluna customer_num.
Lança o programa referido antes (demo_tst) e obtém o seu código de retorno (número de sequential scans executado na tabela).
Mostra o resultado do EXPLAIN contendo as queries feitas pelo programa demo_tst

O código está no fim do artigo, caso pretenda executar o teste. Os passos serão:

Compilar o demo_tst com: esql -o demo_tst demo_tst.ec
Executar o SHELL script com: ./demo.sh

Em princípio o resultado será:

Para a execução com AUTO_REPREPARE = 1:

Serão executados três sequential scans e o EXPLAIN terá apenas um plano e três execuções similares.

Para a execução com AUTO_REPREPARE = 5:

Será executado apenas um sequential scan (da primeira execução pela utilização do valor "1") e dois acessos por índice (este segundo plano obtido pelo uso do valor "115" na segunda execução, re-optimizado porque entre a primeira e segunda execução fizemos um UPDATE STATISTICS). A terceira execução terá sempre o mesmo plano da segunda, pois não há nada entre ambas que cause uma re-optimização.

Conclusão

O (relativamente) novo valor 5 permite que queries preparadas possam ser re-optimizadas logo que sejam refrescadas estatísticas nas tabelas envolvidas, permitindo que as queries beneficiem automaticamente de planos melhoradas, sem re-inicio das aplicações. Também evita o erro -710 como o mais habitual valor 1 permite.

Note-se que é frequente que os clientes não tenham o AUTO_REPREPARE explicitamente definido, mas em alguns casos acaba por assumir o valor 1, caso tenham o AUTO_TUNE a 1. Mas para beneficiarmos desta funcionalidade estendida é necessário defini-lo explicitamente a 5.

O valor 3 e 7 são semelhantes respectivamente aos valores 1 e 5, mas no modo "optimista" onde o sistema não vai verificar se é necessário fazer a re-optimização se a query correu com sucesso há menos de um segundo. Isto deixa naturalmente margem para ocorrência do erro -710 se uma query fôr executada constantemente.

Tendo isto em conta há uma questão que salta à vista: Haverá razão para ter outro valor que não o 5 neste parâmetro?

The code

demo_tst.ec:

/****************************************************************************

* Licensed Material - Property Of IBM * * IBM Informix Client-SDK * * (c) Copyright IBM Corporation 1997, 2013. All rights reserved. * (c) Copyright HCL Technologies Ltd. 2017. All Rights Reserved. * **************************************************************************** */ #include <stdio.h> #include <string.h> #include <unistd.h> EXEC SQL define FNAME_LEN 15; EXEC SQL define LNAME_LEN 15; int main() { EXEC SQL BEGIN DECLARE SECTION; char fname[ FNAME_LEN + 1 ]; char lname[ LNAME_LEN + 1 ]; integer customer_num = 1, seq_scans; EXEC SQL END DECLARE SECTION; int count; printf( "DEMO1 Sample ESQL Program running.\n\n"); EXEC SQL WHENEVER ERROR STOP; EXEC SQL connect to 'stores'; EXEC SQL SET EXPLAIN ON; EXEC SQL PREPARE p1 FROM "select fname, lname from customer_tst where customer_num > ?"; printf("======== Statment prepared ====================\n"); EXEC SQL declare democursor cursor for p1; printf("== Opening the cursor with value 1 ============\n"); EXEC SQL open democursor USING :customer_num; count=0; for (;;) { EXEC SQL fetch democursor into :fname, :lname; if (strncmp(SQLSTATE, "00", 2) != 0) break; count++; if ( count == 1 ) printf("Frst row: %s %s\n",fname, lname); } printf("%d rows were returned\n", count); if (strncmp(SQLSTATE, "02", 2) != 0) printf("SQLSTATE after fetch is %s\n", SQLSTATE); EXEC SQL close democursor; printf("== Updating statistics for table =====\n"); EXEC SQL UPDATE STATISTICS LOW FOR TABLE customer_tst; printf("======== Reopening the cursor again with 115 ==\n"); customer_num = 115; EXEC SQL open democursor USING :customer_num; count=0; for (;;) { EXEC SQL fetch democursor into :fname, :lname; if (strncmp(SQLSTATE, "00", 2) != 0) break; count++; if ( count == 1 ) printf("Frst row: %s %s\n",fname, lname); } printf("%d rows were returned\n", count); if (strncmp(SQLSTATE, "02", 2) != 0) printf("SQLSTATE after fetch is %s\n", SQLSTATE); EXEC SQL close democursor; printf("======== Reopening the cursor again with original 1 ==\n"); customer_num = 1; EXEC SQL open democursor USING :customer_num; count=0; for (;;) { EXEC SQL fetch democursor into :fname, :lname; if (strncmp(SQLSTATE, "00", 2) != 0) break; count++; if ( count == 1 ) printf("Frst row: %s %s\n",fname, lname); } printf("%d rows were returned\n", count); if (strncmp(SQLSTATE, "02", 2) != 0) printf("SQLSTATE after fetch is %s\n", SQLSTATE); EXEC SQL close democursor; EXEC SQL free democursor; EXEC SQL SET EXPLAIN OFF; EXEC SQL SELECT t2.pf_seqscans INTO :seq_scans FROM sysmaster:systabnames t1, sysmaster:sysptntab t2 WHERE t1.partnum = t2.partnum AND t1.dbsname = 'stores' and t1.tabname = 'customer_tst'; EXEC SQL disconnect current; printf("\nDEMO1 Sample Program over.\n\n"); printf("======== Sequential scans executed on customer_tst table: %d =======\n",seq_scans); return(seq_scans); }

test.sh:

#!/bin/bash run_actions() { AUTO_REPREPARE_MODE=$1 onmode -wm AUTO_REPREPARE=$AUTO_REPREPARE_MODE printf -- "------------------------------------------------------------------------------------------------\nPreparing the table (customer_tst) and launching the program demo1\n------------------------------------------------------------------------------------------------\n" dbaccess stores <<EOF DROP TABLE IF EXISTS customer_tst; CREATE TABLE customer_tst AS SELECT * FROM customer; CREATE INDEX cust_fis_pk ON customer_tst(customer_num); EOF ./demo_tst NUM_SEQSCANS=$? cat sqexplain.out case $NUM_SEQSCANS in 1) printf -- "------------------------------------------------------------------------------------------------\nOnly one sequential scan was done. That was the first. The plan changed between executions\n------------------------------------------------------------------------------------------------\n" if [ "X${AUTO_REPREPARE_MODE}" = "X5" ] then printf -- "------------------------------------------------------------------------------------------------\nThis is expected with AUTO_REPREPARE set to 5\n------------------------------------------------------------------------------------------------\n" else printf -- "------------------------------------------------------------------------------------------------\nThis is NOT expected with AUTO_REPREPARE set to 1\n------------------------------------------------------------------------------------------------\n" fi ;; 3) printf -- "------------------------------------------------------------------------------------------------\nThree sequential scans were done. The plan didn't change between executions\n------------------------------------------------------------------------------------------------\n" if [ "X${AUTO_REPREPARE_MODE}" = "X1" ] then printf -- "------------------------------------------------------------------------------------------------\nThis is expected with AUTO_REPREPARE set to 1 or unset if AUTO_TUNE is set to 1\n------------------------------------------------------------------------------------------------\n" else printf -- "------------------------------------------------------------------------------------------------\nThis is NOT expected with AUTO_REPREPARE set to 5\n------------------------------------------------------------------------------------------------\n" fi ;; *) printf -- "------------------------------------------------------------------------------------------------\nUnexpected value for number of sequential scans ($NUM_SEQSCANS) in customer_tst table. No external access to this table should be done during testing\n------------------------------------------------------------------------------------------------\n" exit 1 ;; esac printf -- "------------------------------------------------------------------------------------------------\nPlease check query plans. If three sequential scans were executed it should show only one query plan and three executions.\nIf only one sequential scan was executed it should show two plans and an execution for first and two for second\n------------------------------------------------------------------------------------------------\n" } printf -- "------------------------------------------------------------------------------------------------\nRunning for AUTO_REPREPARE = 1\n------------------------------------------------------------------------------------------------\n" rm -f sqexplain.out run_actions 1 printf "*************************************************************************\nPRESS ENTER TO CONTINUE WITH SECOND PART OF THE TEST\n*************************************************************************\n" read DUMMY printf "*************************************************************************\nSTARTING SECOND PART OF TEST\n*************************************************************************\n" printf -- "------------------------------------------------------------------------------------------------\nRunning for AUTO_REPREPARE = 5\n------------------------------------------------------------------------------------------------\n" rm -f sqexplain.out run_actions 5 dbaccess stores <<EOF DROP TABLE IF EXISTS customer_tst; EOF

New and upcoming features

2024-02-29T23:01:00.003+00:00

Announcement of a webcast covering recent and upcoming Informix features (original version here)

English version
IIUG website recently published the announcement of a Webcast covering recent features (in version 14.10) as well as some upcoming news related to future major version (15). The webcast will happen on March 28 at 3PM GMT time. You can find the details and register here:
https://www.iiug.org/event/ibm-informix-whats-new-and-whats-upcoming-thu-mar-28-2024-1100-am-edt/

Versão Portuguesa
O site do IIUG publicou recentemente um anúncio de um webcast cobrindo funcionalidades recentes (da versão 14.10) bem como algumas novidades relacionadas com a futura versão (15). A apresentação terá lugar no dia 28 de Março às 15H GMT. Pode encontrar os detalhes e registar-se no seguinte endereço:
https://www.iiug.org/event/ibm-informix-whats-new-and-whats-upcoming-thu-mar-28-2024-1100-am-edt/

Aha! It's worth it / Aha! Vale a pena!

2023-06-16T20:00:00.004+01:00

The joys of Aha (original version here)

English version

In my most recent article I mentioned several features that will be implemented in the future major release of Informix and wrote that several of them came from "customer" requests and a couple of them I had inserted myself in the current or old Request For Enhancements page (now called Aha).
It just happens that today I had to open a new request for another IBM product, and the site listed my requests... And some of them are quite interesting:

Allow remote query execution inside a TRUSTED CONTEXT (opened in 2019)
Mentioned in the article and refused. For me this will still prevent the use of SET SESSION AUTHORIZATION...
MSG_DATE format should follow $DBDATE if defined (opened in 2016)
Refused although the parameter was changed in 14.10.FC4 to allow for another (fixed) format.
The code was changed to a less flexible option...
Allow PAM in OleDB clients (for password mode) (opened in 2016)
Refused. This means client applications with OleDB can't use PAM ports. The situation is even more complex because any client which doesn't send the CLIENT_PAM_CAPABLE will be prevented to connect to a PAM enabled port when that is irrelevant for user/password authentication when using PAM. This includes 3rd party drivers for example.
SQL interface to obtain the temporary space usage (tables, hash, sorts...) (opened in 2015)
Implemented!
Add SID to audit log (opened in 2015)
Mentioned in the article and one to be implemented in vNext!
Require NODEFDAC as a server side general setup (opened in 2014)
Refused. We still have the server grant all privileges in non-ANSI databases by default. It would be a nice thing to be added since there are plans to implement certain ANSI features in non-ANSI databases!
Allow DBA to re-initialize OS process cache created by the resolver routines (opened in 2014)
Refused. This means that if a change is made in the DNS infra-structure we need to restart the database engine. The issue is documented in this blog article which includes an hack documented in this blog that may workaround this but I doubt any customer would want to do that (I already did it in a customer...). There's another workaround documented here which is a bit more elegant.
Improve performance of L1/L2 backups (opened in 2014)
Marked as "Future consideration". I mentioned this in the vNext article, because the increase in timestamp range will allow the use of L1/L2 in high activity servers, but they'll still be painfully and unnecessarily slow
Allow column ALIAS in HAVING clause (opened in 2014)
Refused. Less compatibility with other RDBMs SQL and more complicated SQLs
Allow "group commit" as other RDBMS (opened in 2014)
Marked as "Future consideration". A possible performance optimization.
Obtain the query plan of a running query (opened in 2013)
Mentioned in the article and one to be implemented in vNext!
Upgrade of secondary server without restore from primary (opened in 2013)
Refused, although we can do it with a lot of limitations which I think we wouldn't have with the solution I proposed

I just mentioned the features I requested in Aha (there are a few more I suggested in the previous site). Many of them were refused. Some were or will be implemented. And some are still marked for "future consideration" which means they may still be implemented. It may seem that the majority is ignored/refused, so why do I think it's worth it? Because it may take around 5m to open it... it's easy! And it's somehow rewarding when you see that development actually implemented something you requested.

Versão Portuguesa

No meu artigo mais recente mencionei algumas funcionalidades que serão implementadas na próxima versão do Informix e indiquei que algumas delas derivam de pedidos de "clientes" e um par delas teriam sido inseridas por mim no actual ou antigo site de pedidos de melhorias (agora chamado Aha).
Por coincidência, hoje estive a abrir mais um pedido para outro produto IBM, e no site reparei na lista dos meus pedidos... alguns são bastante interessantes:

Allow remote query execution inside a TRUSTED CONTEXT (aberto em 2019)
Mencionado no artigo e recusado. Para mim isto irá impedir muitas utilizações da instrução SET SESSION AUTHORIZATION...
MSG_DATE format should follow $DBDATE if defined (aberto em 2016)
Recusado ainda que o parâmetro tenha sido alterado na versão 14.10.FC4 para permitir outro formato (fixo).
Allow PAM in OleDB clients (for password mode) (aberto em 2016)
Recusado. Isto implica que aplicações clientes que usem OleDB não podem usar portos configurados com PAM. Esta situação é ainda mais complexa, pois qualquer cliente que não envie a "variável" CLIENT_PAM_CAPABLE será impedido de conectar-se a um port configurado com PAM, quando tal é irrelevante para autenticações com utilizador/senha, mesmo que tenham outros módulos PAM. Isto incluí drivers de terceiros por exemplo.
SQL interface to obtain the temporary space usage (tables, hash, sorts...) (aberto em 2015)
Implementado!
Add SID to audit log (aberto em 2015)
Mencionado no artigo e para ser implementado na vNext!
Require NODEFDAC as a server side general setup (aberto em 2014)
Recusado. Ainda temos o servidor a dar todos os privilégis em bases de dados não-ANSI. Seria uma boa adição, já que há planos de implementar certas características de bases de dados ANSI em bases de dados não-ANSI!
Allow DBA to re-initialize OS process cache created by the resolver routines (aberto em 2014)
Recusado. Isto implica que se fizermos uma mudança na infra-estrutura de DNS teremos de re-iniciar o Informix. O problema está descrito neste artigo e incluí um truque que pode ser utilizado como workaround mas duvido que os clientes o queiram usar (eu já o usei num cliente). Num outro artigo descrevo uma forma mais elegante de contornar o problema.
Improve performance of L1/L2 backups (aberto em 2014)
Marcado como "Future consideration". Eu mencionei isto no artigo sobre a vNex, porque o aumento do tamanho do timestamp vai permitir usar os arquivos L1/L2 em ambientes com muita actividade, mas estes continuarão a ser desnecessariamente lentos.
Allow column ALIAS in HAVING clause (aberto em 2014)
Recusado. Implica menor compatibilidade com SQL de outros RDBMS e SQLs mais complicados.
Allow "group commit" as other RDBMS (aberto em 2014)
Marcado como "Future consideration". Uma possível melhoria de performance.
Obtain the query plan of a running query (aberto em 2013)
Mencionado no artigo e um a ser implementado na vNext!
Upgrade of secondary server without restore from primary (aberto em 2013)
Recusado, embora se possa fazer com uma série de limitações, que eu penso que não existiriam com a solução que propus.

Apenas mencionei os pedidos que fiz no Aha (haveria outras que sugeri no site antigo). Muitos foram recusados. Alguns foram ou serão implementados. E alguns estão marcados como "Future consideration" o que significa que poderão ainda ser implementados. Pode parecer que a maioria é ignorado/recusado, portanto porque acredito que vale a pena? Porque pode demorar cerca de 5m a abrir um pedido. É fácil! E é de alguma forma gratificante quando vemos que o desenvolvimento efectivamente implementou algo que sugerimos.

Yes, I'm still here. And soon so vNext will be / Sim, ainda estou por cá. E em breve a vNext também

2023-06-14T01:25:00.030+01:00

A return or just a notice about vNext (original version here)

English version

Long time "no see"... I can't really remember about my last post, but apparently it was in 2019, and I only posted two articles during that year. A long time has passed, and the reasons for not posting are the usual ones...: I've been working with other products (although I never stopped working with Informix), lack of time, other priorities etc., etc... That doesn't really matter and this article doesn't necessarily mean I'll be posting frequently in the future... Though I remind I started posting when IBM was about to release version 11.10 (Cheetah). New stuff naturally triggers the will to share some views and (hopefully) some knowledge. And we're getting close to a new major version (currently only known, at least by me, as "vNext"). And a new major version should bring new and interesting stuff... even considering the "continuous delivery" that briefly means that when a feature is ready it will be out of the door in the next fixpack, which naturally means "major" versions may seem to contain very few new things.

Recently my colleague Scott Pickett shared some insights about vNext in an IIUG webcast. And the list of announced changes pushed me write this article... The list seems long and nice. And the focus seems to be the expansion or removal of some internal limits, which were last changed in V10 (March 2005).

This is a slide of the presentation and shows some of the limits that should change. One not listed here, but under consideration is the maximum row size. From the above I'd like to highlight and comment on some:

Larger partitions
Many customers are hitting the current limit. Note however that if they're hitting this limit, you should probably partition your data
More rows per page
Extremely important because it means we can use larger page sizes without the issue of wasting space in each page
Timestamp moving to 8-byte
An end to the issue with incremental backups? Yes, probably, but just this change won't solve the slowness of incremental backups (because we need to read all the pages to identify the ones we should send to the backup)

Besides the focus on limits, development is also concentrating efforts on customer requests, entered through the Aha website. Among these I'd like to highlight a few:

Obtain the query plan of a running query
I've requested this in the website before Aha. I wrote several articles about this (including an hack to try to show this should be easy to implement). Need I say more about this? Only that it comes too late... but apparently it will appear in a proper way, because it can be obtained with "onstat" command and through a pseudo table (although with a limit of 32K)
Storing large objects in a file system
This will allow Smart Blobs to be stored in a filesystem, external to the database system. I have some mixed feelings about this. I'd say that because the filesystem is not a transactional system, this may open up possibilities to create some inconsistency between the filesystem and the metadata in the database. I hope that in the future there will be ways to check this. But on the other hand, this functionality will allow much easier maintenance and backup of this type of data. Whenever I see customers using Smart Blobs I remember a specific customer where most of their database is composed of Smart Blobs. And they have serious issues with backups for example (the backup infra-structure is not properly sized for the load this implies). Filesystem backups can be much more efficient because they already support incremental archiving. Obviously the downside is that a full restore will probably mean dual restore sessions (database and filesystem). But we need more info before deciding if this is a good thing or not. I think it clearly opens up possibilities to solve specific issues at very large databases where most of the data is composed of Smart BLOBs
CDC log capture from secondary
CDC means change data capture, and Informix provides a way (API) for external applications to capture changes that are then replicated by them to external systems. Incidentally IBM has a product called InfoSphere Change Data Capture, and I've been doing a lot of work with it lately. The ability to attach these 3rd party (including IBM other products in this classification) to the secondary servers is a feature I can imagine a lot of customers using in order to lower the load on the primary servers.
CREATE/ALTER DATABASE - implicit transactions, owner qualified names unique, cursors for update
This seems to be adding ANSI features like proper object owner nomenclature and automatic start of transactions to non-ANSI mode databases. Seems interesting for increased compatibility with other RDBMs, but I'd say some of them (implicit transactions) would require application changes. But, being new options that's good. We should like options!
Something I'd like to see in non-ANSI databases that we already have in ANSI databases is the raising of an error if we try to INSERT/UPDATE CHAR like data that doesn't fit in the field length (currently we silently truncate it)
Add SID to audit log
I also requested this many years ago in the old RFE site. In fact I recall some email exchanges with Jonathan Leffler (old timers will recognize the name for sure) about this. It won't solve all the issues, but it will allow an audit log analysis to reconstruct a sequence of actions, which currently we can't understand, because the logs only contain the client PID (process ID) and for Java applications that's always -1, meaning we see a bunch of audit entries but can't really correlate them.
Allow indexes to be made invisible to queries
This allows a DBA to "test" the removal of an index (applications and query optimizer will stop seeing this index) while still keeping and maintaining the index... if the result is bad we can just "reactivate" it, without having to rebuild the index which can be painful
Updated Global Language Support (GLS) (Phase 1)
Not much information about this (current, standard code sets are mentioned). But I'd like to emphasize that it mentions "Phase 1")
Informix should not need ROOT permissions
It's stated that the default installation will be "non-root" method. This looks nice from a security perspective but it raises some issues (for authentication for example). I'll have to wait and see the implications of this feature. But it will be important, assuming the default installation method will change
Incremental Archives
Not new right? Yes. We already have them (at least in theory), but high activity sites may not be able to use them due to the short timestamp we're using. And this limit will apparently change (see slide above). However, to have proper incremental archives we would need something else: A quick method to identify changed pages without having to read all the instances pages (current method). And I see no mention to this issue
SET SCHEMA: Informix should support switching 'schemas' in the middle of a transaction
Currently there's a limitation on the statement "SET SESSION AUTHORIZATION" where it can't be used in the middle of a transaction. Apparently there are plans to remove this limitation. However, I think a bit of context is required here. This statement could be very useful to allow applications using application server to "propagate" the final user identity to the database, while using a pool of connections opened with a single "application user". This is very important when old systems that rely on the user identity for logging/auditing purposes on the database (using triggers for example) start to get used also by application servers which normally authenticate with a single user and open a series of connections that will be shared by different "application sessions".
Now... this new feature may facilitate this, but what I've seen in several customers preventing this usage is that during a "session" that changed the authorization with SET SESSION AUTHORIZATION we CANNOT do remote SQL. And by "remote" I mean any action in another database on the same instance. And many customers have several databases that are used by a single application using this type of "remote SQL". So that limitation should also be removed, otherwise I think the usefulness of the feature will be very limited

I did not cover all the new mentioned features. For a full list, please check the webcast. I've only focused on the ones I think are more important or the ones I had comments about. Your preferences may vary of course, so the best is to check the source of information.

The last question is of course "When?". As usual the dates may vary... and there is no compromise about an ETA, but let's assume for now it should be this year. And we're about half way through...

Let's hope I'm able to continue covering these new features here! Glad to be "back", even if it was just this time.

Versão Portuguesa

Há quanto tempo... Na realidade não me lembro quando fiz a última publicação, mas aparentemente foi em 2019, e só publiquei duas vezes nesse ano. Muito tempo passou e as razões para não publicar são as habituais...: Tenho estado a trabalhar com outros produtos (ainda que nunca tenha deixado de trabalhar com Informix), falta de tempo, outras prioridades etc., etc... Isso agora não interessa, e este artigo não quer necessariamente dizer que irei publicar com frequência no futuro... Embora me recorde que comecei a publicar quando a IBM estava para lançar a V11.10 (Cheetah). Novidades naturalmente inspiram a partilha de perspectivas e (espero) algum conhecimento. E estamos a chegar perto de uma nova versão (actualmente apenas conhecida por "vNext", pelo menos por mim). E uma nova versão deverá trazer uma série de coisas interessantes... mesmo no contexto do "continuous delivery" que sumariamente significa que assim que uma funcionalidade está pronta será lançada no próximo fixpack, o que naturalmente "esvazia" um pouco os lançamentos de novas versões.

Recentemente o meu colega Scott Pickett partilhou algumas novidades sobre a vNext num webcast do IIUG. E a lista de modificaões anunciadas fez-me escrever este artigo... a lista parece longa e interessante. E o foco parece ser no aumento ou remoção de alguns limites internos, que foram revistos pela última vez na V10 (Março de 2005)

Isto é um diapositivo dessa apresentação e mostra alguns dos limites que deverão ser alterados. Um que não está aqui listado mas que está a ser analisado é o tamanho máximo de uma linha. Dos apresentados acima gostaria de salientar e comentar alguns:

Partições maiores
Muitos clientes estão a atingir este limite. Note-se no entanto que se atingimos este limite, provavelmente já deveríamos ter particionado os dados
Mais registos por página
Extremamente importante porque significa que poderemos usar tamanhos de página maiores sem receio de desperdiçar espaço em cada página
Alteração do Timestamp para 8 bytes
Um fim para o problema dos backups incrementais? Sim, provavelmente, mas esta alteração por si só não resolverá o tema da performance deste tipo de backups (porque temos de ler todas as páginas para identificar aquelas que devem ser colocadas no backup)

Para além do foco nos limites, o desenvolvimento está também a concentrar esforços nos pedidos dos clientes, introduzidos no site Aha . Nestes, gostaria de salientar alguns:

Obter o plano de execução de uma query em execução
Pedi isto no site anterior ao Aha. Escrevi vários artigos sobre isto (incluindo um truque para tentar mostrar que a implementação não deveria ser difícil). Preciso de dizer algo mais sobre o tema? Apenas que vem tarde... Mas aparentemente vai aparecer da forma correta, pois poderá ser obtido através de uma opção do comando "onstat" e também por via de uma view (ainda que limitado a 32K)
Guardar Smart Large Objects num filesystem
Isto permitirá que os Smart BLOBs sejam guardados como ficheiros num filesystem externo ao sistema de base de dados. Tenho sentimentos contraditórios em relação a isto. Dado que os sistemas de ficheiros não são sistemas transaccionais, isto poderá abrir a possibilidade de haver inconsistências entre o conteúdo do sistema de ficheiros e a metadata na base de dados. Espero que o futuro traga ferramentas para verificar isto. Mas por outro lado, esta funcionalidade irá permitir uma gestão e backups deste tipo de dados muito mais fácil. Sempre que vejo clientes a usarem Smart BLOBs lembro-me de um determinado cliente em que a esmagadora maioria do espaço são Smart BLOBs. E dos problemas que daí advêm, nomeadamente em termos de backup (a infra-estrutura de backups está claramente sub-dimensionada para a quantidade de dados que têm). Os backups de filesystem podem ser muito mais eficientes porque já permitem de forma muito simples backups incrementais. A desvantagem deste tipo de solução é que um possível restore implicará sessões de restore ao nível da base de dados e do filesystem. Mas precisamos de mais informação para decidir se isto será uma boa funcionalidade ou não. Penso que isto claramente abre possibilidades para resolução de problemas em bases de dados muito grandes onde a maioria dos dados são Smart BLOBs.
Captura de logs para CDC a partir de um secundário
CDC significa "change data capture" e o Informix fornece uma forma (API) para que aplicações externas capturem alterações que depois serão replicadas para sistemas externos. A IBM tem um produto chamado InfoSphere Change Data Capture, e eu tenho feito bastante trabalho com ele nos últimos tempos. A capacidade de ligar estes produtos de terceiros (estou a incluir produtos externos ao Informix, ainda que da IBM) aos nós secundários é uma funcionalidade que imagino ver muitos clientes a quererem usar para baixar a carga sobre o servidor primário
CREATE/ALTER DATABASE - transações implícitas, nomes com qualificação de owner únicos, cursores para update
Parece ser a adição de funcionalidades ANSI, como nomenclatura de objectos correctamente qualificadas com identificação de owner e início automático de transações, a bases de dados criadas sem modo ANSI. Parece interessante para compatibilidade com outros RDBMS, mas diria que algumas (transações implícitas) implicarão alterações de aplicações. Mas sendo uma opção nova parece bom. Devemos apreciar o facto de termos opções!
Uma característica de base de dados ANSI que gostaria de ver em bases de dados não-ANSI é a ocorrência de um erro sempre que tentamos inserir ou alterar dados do tipo CHAR que não caibam na definição do campo. Actualmente truncamos os dados sem dar erro.
Adicionar o SID ao log de audit
Também pedi isto há muitos anos no antigo site de RFE (Requests For Enhancement). Inclusivamente lembro-me de uma troca de emails com o Jonathan Leffler (os mais antigos certamente reconhecem o nome) acerca deste tema. Não resolverá todos os problemas, mas permitirá reconstituir uma sequência de acções através da análise dos logs de audit. Actualmente tal não é possível porque o único elo de ligação entre as acções é o PID (ID de processo) do cliente, mas em aplicações Java isto aparece sempre como -1, o que impede a correlação entre as acções que vemos nos logs de audit
Permitir que os índices fiquem invisíveis às queries
Isto permite que um DBA possa testar a remoção de um índice (as aplicações e o optimizador de queries deixarão de os ver) fazendo no entanto com que o índice continue a ser actualizado... Se o resultado for mau, podemos simplesmente reverter sem ter de reconstruir o índice que pode ser uma operação muito pesada
Actualização Global Language Support (GLS) (fase 1)
Não há muita informação sobre isto (menção ao uso de códigos de caracteres standardizados e actualizados). Mas gostaria de salientar que está marcado como "fase 1"
O Informix não deverá precisar de permissões de ROOT
É indicado que a instalação padrão passará a ser "sem root". Isto soa bem do ponto de vista da segurança, mas levanta algumas questões (relativas à autenticação por exemplo). Terei de esperar para ver as implicações desta funcionalidade. Mas considerando que o método padrão mudará será algo importante no futuro
Arquivos incrementais
Nada de novo, certo? Sim. Já existem arquivos incrementais, mas instalações com muita actividade podem estar impedidas de os usar, devido ao pouco tamanho do timestamp com que as páginas são marcadas. E isto será mudado (ver diapositivo acima). No entanto, para termos arquivos incrementais optimizados necessitaríamos de outra coisa: Uma forma rápida de identificar as páginas alteradas (desde o último arquivo) sem ter de ler todas as páginas da instância (método actual). E não vi nenhuma referência a este tema
SET SCHEMA: Informix deveria suportar a troca de 'schemas' no decorrer de uma transação
Actualmente há uma limitação na instrução "SET SESSION AUTHORIZATION" que é a mesma não poder ser usada no meio de uma transação. Aparentemente há planos para remover esta limitação. Mas penso que temos de adicionar aqui algum contexto. Esta instrução pode ser muito útil para permitir que aplicações que usam servidores aplicacionais possam "propagar" a identidade do utilizador final (usada entre o cliente e o servidor aplicacional) até à base de dados, quando a ligação à base de dados é feita com uma pool de ligações aberta com um único utilizador aplicacional. Isto é muito importante em sistemas antigos que dependem da identidade do utilizador para efeitos de logging/auditing na base de dados (usando triggers por exemplo), quando começam a ser usados também por aplicações através de servidores aplicacionais, que abrem ligações à base de dados com um utilizador aplicacional.
Ora... esta funcionalidade pode facilitar isso, mas o que vi em vários clientes que impede este uso é que durante uma "sessão" onde tenha sido usada a instrução "SET SESSION AUTHORIZATION" não podemos executar nenhum tipo de "SQL remoto". E por "remoto" quero dizer qualquer acção noutra base de dados ainda que na mesma instância. E muitos clientes têm várias bases de dados que são usadas por uma única aplicação com este tipo de "SQL remoto". Portanto esta limitação deveria ser removida, caso contrário penso que a funcionalidade continuará a estar limitada.

Não cobri todas as funcionalidades mencionadas na sessão referida. Para uma lista completa por favor assista ao webcast. Apenas foquei as que me parecem mais importantes ou sobre as quais tinha comentários a fazer. As preferências de cada um variam naturalmente, pelo que o melhor é consultar a fonte da informação.

A última questão é "Quando?". Como é hábito, as datas podem variar.... e não existe qualquer compromisso quanto a uma possível data de disponibilização, mas podemos assumir que será este ano. E o ano já vai a meio...

Vamos esperar que eu continue a cobrir estas novas funcionalidades. Estou contente por estar "de volta" mesmo que não haja muita continuidade nestes artigos.

What's new? Check it! / O que temos de novo? Veja por si!

2019-10-16T02:51:00.000+01:00

Very quick notice about good news for Informix (original version here)

English version
It has been a long day, but I still have 5m to share a couple of things... I had the pleasure of meeting Scott Picket, a distinguished contributor for the Informix community, and as usual it was enlightening and fun. During the conversation I "complained" about the lack of time to update this blog, in spite of having several topics I'd like to cover, considering the new features that we're seeing popping up in Informix. And when I got home, while checking the email I just noticed the perfect (and lazy) way to do an update on the blog. IIUG, who recently organized the annual conference just informed the users that the session's presentations are ready for download here: http://www.iiug.org/sessions.zip
As usual, there are lots of interesting presentations, but I'd like to highlight one in particular: Nicholas Geib and Jeff McMahon "What's new in Informix". Some of the things mentioned were new to me... Haven't seen them even in internal documents...

Versão Portuguesa
Foi um dia longo, mas ainda tenho 5 minutos para partilhar um par de coisas... Tive o prazer de estar com Scott Picket, um proeminente participante da comunidade Informix, e como habitualmente foi esclarecedor e divertido. Durante a conversa "queixei-me" da falta de tempo para atualizar este blog, não obstante existirem vários tópicos que gostaria de desenvolver, considerando as novas funcionalidades que têm sido adicionadas ao produto. E quando cheguei a casa, ao rever o correio, descubro a forma perfeita (e preguiçosa) de fazer um artigo aqui no blog. O IIUG que recentemente organizou a conferência anual de utilizadores, acaba de informar que as apresentações das sessões estão disponíveis aqui: http://www.iiug.org/sessions.zip
Como habitualmente há muitas apresentações interessantes, mas gostaria de salientar uma em particular: A do Nicholas Geib e do Jeff McMahon "What's new in Informix". Algumas das funcionalidades mencionadas são novidade para mim... Não tinha visto nenhuma referência às mesmas, mesmo em documentação interna...

Informix 14.1 : License changes / Mudanças no licenciamento

2019-03-24T18:35:00.000+00:00

A few details about Informix 14.10 license terms (original version here)

English version
Informix 14.10 introduces a few changes in terms of licenses. But fear not... the changes are for better... although one aspect may cause some confusion, and that's why I'm starting the review of 14.1 changes by this aspect.
Let's start by what can cause some confusion. IBM maintains the following Informix editions:

No cost editions

Informix Innovator-C edition
Informix Developer edition

Cost editions

Informix Express edition
Informix Workgroup edition
Informix Enterprise edition
Informix Advanced Enterprise edition
Informix Advanced Developer edition

You may notice that the Informix Advanced Workgroup edition is no longer an option.
But if you see the download package you'll probably see ONLY the Informix Developer edition, even if your organization is entitled for Express/Workgroup/Enterprise/Advenced Enterprise or Advanced Developer edition(s). Why? Well because one of the features introduced in 14.1 is the Informix Edition Installer which basically permits that an administrator changes the edition license he has installed. We can also use the License Installer to define the edition at installation time. So, and because of that you'll have the Developer edition package and one of more License Installer packages available for your download. You should decompress both packages to the same temporary installation director like:



[root@stardust install_dir]# pwd

/ifmx_data/install_dir

[root@stardust install_dir]# ls -lia

total 391008

729089 drwxr-xr-x  3 root     root          4096 Mar 14 11:03 .

     2 drwx------ 12 informix informix      4096 Mar 14 11:02 ..

729090 -rw-r--r--  1 root     root     389191680 Mar 14 11:03 INFORMIX_DEV_ED_14.10.FC1_Linux.tar

729091 -rw-r--r--  1 root     root      10783435 Mar 14 11:03 INFORMIX_EE_License_Ins_14.10.FC1.tar

729092 drwxr-xr-x  3 root     root          4096 Mar 14 11:48 install

[root@stardust install_dir]# cd install

[root@stardust install]# ls -lia

total 391980

729092 drwxr-xr-x 3 root root      4096 Mar 14 11:48 .

729089 drwxr-xr-x 3 root root      4096 Mar 14 11:03 ..

729095 drwxr-xr-x 2 root root      4096 Feb 20 21:41 doc

729101 -rwxr-xr-x 1 root root  11811722 Feb 18 15:24 ee_edition.jar

729093 -rwxr-xr-x 1 root root 388159473 Feb 20 21:46 ids_install

729099 -rw-r--r-- 1 root root      1952 Feb 20 21:46 ids.properties

729094 -rwxr-xr-x 1 root root    980144 Feb 20 21:46 onsecurity

729102 -rw-rw-r-- 1 root root      1173 Feb 18 15:23 README-Edition.txt

729100 -rw-r--r-- 1 root root      1959 Feb 20 21:41 README_ids.txt

[root@stardust install]#

As you can see in bold, there is the usual "ids_install" script and the "ee_edition.jar" (the "ee" stands for Enterprise edition). So this will be an Enterprise Edition installation.
If needed we can later change the edition by decompressing the License package and run:



$INFORMIXDIR/jvm/jre/bin/java -jar ee_edition.jar -i <console|gui>

NOTE: At the time of this writing, some packages have the "*.tar" extension, but they're actually "*.zip" files. If you have issues to "untar" a TAR file just try with unzip. Hopefully this will be fixed shortly.
So, this is the difference that may cause some confusion... What other license changes have been introduced?:

A new license model called Virtual Processor was introduced. It's available for Express, Workgroup, Enterprise and Advanced Enterprise editions.
It's basically based on the number of cores made available to a virtual server. It allows a better understanding of the license model when the number of cores available for a number of virtual servers might exceed the number of real cores. Imagining a server with 16 physical cores supporting a number of servers where the sum of the PVUs for those servers could be higher than the equivalent PVUs for the physical server (let's say 20), this metric clearly defines 16 Virtual CPUs as the maximum charge.
The limits for Informix Workgroup edition were increased. Now we can use it until the limit of 24 CPU VPs (as defined by the NUMCPUVPS parameter) - previously was 16 - and the memory limit was increased to 32GB (as defined by SHMTOTAL) when previously it was 16GB
The storage optimization feature which was the only extra available on top of Enterprise Edition is now included in that version

So, in summary, one edition was discontinued (Advanced Workgroup), a new license metric was introduced which may help to clarify the required entitlements in some cases, new increased limits for Workgroup Edition and the inclusion of compression in Enterprise edition. All in all, mostly good news.
More articles will come more focused on the technical enhancements of 14.10

Versão Portuguesa
O Informix 14.10 introduz algumas mudanças no licenciamento. Mas não há que recear... as mudanças são para melhor... apesar de um aspecto poder causar alguma confusão., e é por isso que começo a análise das mudanças na 14.10 por este aspecto.
Comecemos pelo que pode causar alguma confusão. A IBM mantém as seguintes edições de Informix:

Edições sem custo

Informix Innovator-C edition
Informix Developer edition

Edições com custo

Informix Express edition
Informix Workgroup edition
Informix Enterprise edition
Informix Advanced Enterprise edition
Informix Advanced Developer edition

Poderá reparar que a edição Advanced Workgroup já não está disponível.
Mas se examinar os pacotes de download provavelmente só verá a Developer edition, mesmo que a sua organização tenha licenciado a Express/Workgroup/Enterprise/Advenced Enterprise ou a Advanced Developer. Porquê? Bom, porque uma das funcionalidades introduzidas na 14.1 é o Informix Edition Installer que basicamente permite a um administrador mudar a licença de uma instalação de Informix, após a instalação inicial. Também podemos usar o License Installer para definir a edição na altura da instalação. Portanto, e por estas razões, o que verá no seu sitio de downloads será a edição Developer e um ou mais pacotes do License Installer. Deverá descomprimir ambos para o mesmo directório temporário de instalação tal como indicado:



[root@stardust install_dir]# pwd

/ifmx_data/install_dir

[root@stardust install_dir]# ls -lia

total 391008

729089 drwxr-xr-x  3 root     root          4096 Mar 14 11:03 .

     2 drwx------ 12 informix informix      4096 Mar 14 11:02 ..

729090 -rw-r--r--  1 root     root     389191680 Mar 14 11:03 INFORMIX_DEV_ED_14.10.FC1_Linux.tar

729091 -rw-r--r--  1 root     root      10783435 Mar 14 11:03 INFORMIX_EE_License_Ins_14.10.FC1.tar

729092 drwxr-xr-x  3 root     root          4096 Mar 14 11:48 install

[root@stardust instahll_dir]# cd install

[root@stardust install]# ls -lia

total 391980

729092 drwxr-xr-x 3 root root      4096 Mar 14 11:48 .

729089 drwxr-xr-x 3 root root      4096 Mar 14 11:03 ..

729095 drwxr-xr-x 2 root root      4096 Feb 20 21:41 doc

729101 -rwxr-xr-x 1 root root  11811722 Feb 18 15:24 ee_edition.jar

729093 -rwxr-xr-x 1 root root 388159473 Feb 20 21:46 ids_install

729099 -rw-r--r-- 1 root root      1952 Feb 20 21:46 ids.properties

729094 -rwxr-xr-x 1 root root    980144 Feb 20 21:46 onsecurity

729102 -rw-rw-r-- 1 root root      1173 Feb 18 15:23 README-Edition.txt

729100 -rw-r--r-- 1 root root      1959 Feb 20 21:41 README_ids.txt

[root@stardust install]#

Como pode ver salientado, existe o habitual "ids_install" e um ""ee_edition.jar" (o "ee" significa Enterprise edition). Assim, isto dará origem a uma instalação da Enterprise Edition. Se necessário, mais tarde podemos mudar a edição, descomprimindo o pacote do License Installer e executando:



$INFORMIXDIR/jvm/jre/bin/java -jar ee_edition.jar -i <console|gui>

NOTA: à data de criação deste artigo parece haver alguns arquivos com a extensão "*.tar" que são na realidade ficheiros ZIP. Se ao tentar descomprimir um pacote TAR tiver erros tente com o unzip. Esta questão deverá ser corrigida brevemente.
Esta é a diferença que poderá causar alguma confusão... Que outras diferenças no licenciamento foram introduzidas?:

Um novo modelo de licenciamento chamado "Virtual Processor" foi introduzido. Está disponível nas seguintes edições: Express, Workgroup, Enterprise e Advanced Enterprise.
É basicamente baseado no número de cores disponibilizados a um servidor virtual. Permite um melhor entendimento do modelo de licenciamento quando o número de cores disponível a um conjunto de servidores virtuais possa exceder o número de cores físicos. Imagine um servidor com 16 cores físicos, a suportar um conjunto de servidores virtuais onde a soma dos PVUs para esses servidores pudesse ser superior aos PVUs equivalentes para o servidor físico (digamos 20). Esta métrica define claramente os 16 Virtual CPUs como o máximo a cobrar.
Os limites da edição Workgroup foram aumentados. Podemos agora utilizar até 24 CPU VPs (tal como definido no parâmetro NUMCPUVPS - antes eram 16 -, e o limite de memória passou dos 16GB para os 32GB (tal como definido pelo parâmetro SHMTOTAL)
A storage optimization feature ou simplesmente compressão era o único extra disponível em cima da edição Enterprise. Agora está incluído nessa mesma edição, permitindo aos clientes usar a compressão sem custos adicionais.

Portanto, em resumo, uma edição foi descontinuada (Advanced Workgroup), uma nova métrica de licenciamento foi introduzida, o que permite clarificar alguns casos, os limites da edição Workgroup foram aumentados (memória e CPU VPs) e a compressão passa a estar incluída na licença da edição Enterprise. Portanto praticamente tudo para melhor e boas notícias.
Mais artigos virão, mais focados nas melhorias técnicas da versão 14.10.

Informix 14.10 is coming out... / Informix 14.10 está a sair...

2019-03-14T10:22:00.000+00:00

"The report of my death was an exaggeration". (original version here)

English version
I will not waste too much time rumbling about my absence in this blog. Just a fact of life due to lack of time. I haven't stopped working with Informix. Haven't lost interest nor have turned away from it...
But this news are so important that I can't look away and not post something. After the change to HCL many people predicted (again) the dismiss of Informix.... guess what... They were wrong again... HCL/IBM are launching the next major version of Informix (14.10). And they/we also improved communication and asset sharing because the Knowledge Center is already updated ( https://www.ibm.com/support/knowledgecenter/SSGU8G_14.1.0/com.ibm.po.doc/new_features_ce.htm). The packages should be "arriving" at the customer's passport advantage sites and hopefully the trials should be refreshed soon.

I will not detail the new features here, as I hope to do it later with more time. But they range from the technical stuff, immediately visible and usable by customers to commercail licensing changes, and to infra-structure changes that will bring benefits in the future but are relatively "silent" for now.

Stay tuned and take a look at your PA sites... It should arrive there pretty soon...

Versão Portuguesa
Não vou perder muito tempo a explicar a minha ausência deste blog. Apenas um facto da vida causado pela falta de tempo. Não deixei de trabalhar com o Informix. Não perdi o interesse nem me afastei do produto...
Mas esta notícia é tão importante que não poderia olhar para o lado e não publicar nada. Depois da mudança para a HCL, muitas pessoas anteciparam (outra vez) que o Informix morreria... Pois... Enganaram-se outra vez. A HCL/IBM estão a lançar a próxima versão do Informix (14.10). E também melhoraram a comunicação e partilha de ativos, pois a documentação já está atualizada ( https://www.ibm.com/support/knowledgecenter/SSGU8G_14.1.0/com.ibm.po.doc/new_features_ce.htm). Os pacotes devem estar a chegar aos websites do Passport Advantage e as versões de teste devem estar a ser refrescadas brevemente.
Não vou detalhar as novas funcionalidades desta vez, pois espero fazê-lo em breve com mais tempo. Mas vão dos aspetos técnicos disponíveis de imediato para uso dos clientes até a alterações de licenciamento, e melhorias na infra-estruturas que gerarão frutos no futuro mas que por agora são quase "silenciosas"

Mantenham-se atentos e vão verificando o site de downloads... Deve lá chegar dentro em breve...

Backups to cloud / Backups para a núvem

2018-03-09T21:00:00.000+00:00

A webcast about Informix backup integration with cloud storage(original version here)

English version
One of the features in the latest fixpack (12.10.FC10) was the ability to send your backups to the cloud. This can be achieved by integrating PSM (Primary Storage Manager) which is bundled with Informix with cloud services (like Amazon S3 or IBM Cloud Storage, previously Softlayer).

IBM and HCL will present a webcast this March 15 at 9:00AM PDT.
Get more information and register here:

http://ibm.biz/InformixTT_Mar2018

Versão Portuguesa
Uma das funcionalidades deo último fixpack (12.10.FC10) foi a capacidade de enviar os backups para a núvem. Isto pode ser feito integrando o PSM (Primary Storage Manager) que vai incluído com o Informix, com os serviços de armazenamento na núvem (como Amazon S3 ou IBM Cloud Storage, antigamente SoftLayer).

A IBM e a HCL irão apresentar um webcast no dia 15 de Março às 9:00AM PDT dedicado ao tema. Mais informação e registo aqui:

http://ibm.biz/InformixTT_Mar2018

Informix on AWS / Informix na Amazon (AWS)

2018-03-09T17:50:00.001+00:00

A webcast about HCL offering of Informix in the cloud (Amazon) (original version here)

English version
HCL has just made Informix database available on the Amazon AWS cloud. Find out more on this blob post: http://www.informixcommunity.com/blogs/the-power-of-informix-the-convenience-of-aws
And register for a webcast on March 13 at 2:00PM GMT here:

Get more information and register here:
https://register.gotowebinar.com/register/7607840200007271682?

Versão Portuguesa
A HCL acaba de disponibilizar o Informix na núvem da Amazon AWS. Descubra mais neste artigo da Informix Community: http://www.informixcommunity.com/blogs/the-power-of-informix-the-convenience-of-aws

E registe-se num webcast no dia 13 de Março às 2:00PM GMT aqui:
https://register.gotowebinar.com/register/7607840200007271682?

Informix Community (new site) / Comunidade Informix (novo site)

2017-06-25T15:12:00.004+01:00

A new site dedicated to Informix Community was created. (original version can be seen here: http://informix-technology.blogspot.com/2017/06/informix-community-new-site-comunidade.html)

English version
A new site, called "Informix Community" was created. The team behind it is mainly the one who has been working to develop and deliver you favorite database system. After the move to HCL previously announced, the team seems to be highly motivated and apparently is not saving in efforts to continue their work of delivering you the features and information you need.
The site will hopefully receive contributions from other members in the wider Informix community and for now you can already see some articles.
The site will include some resource links like download locations and other goodies.

Please visit, join and participate!

Versão Portuguesa
Um novo site chamado "Informix Community" foi criado. A equipa por trás disto é basicamente a mesma que tem trabalhado para desenvolver e disponibilizar a sua base de dados favorita. Após a mudança para a HCL, anunciada anteriormente, a equipa parece estar altamente motivada e não está a poupar esforços na continuação do seu trabalho de disponibilização de funcionalidades e informações que todos necessitamos
A página irá certamente receber outros contributos de membros da comunidade alargada Informix, e de momento já disponibiliza alguns artigos.
O site irá incluir alguns recursos como ligações para download e outro tipo de informação útil.
Por favor visite, registe-se e participe!

IBM and HCL partnership around Informix / Parceria IBM e HCL em torno do Informix

2017-04-19T00:02:00.000+01:00

IBM and HCL entering a strategic partnership to jointly develop and market the IBM Informix family of products (original version here: http://informix-technology.blogspot.com/2017/04/ibm-and-hcl-partnership-around-informix.html)

English version
A statement by Dan Hernandez, VP Offering Management Analytics, available in IBM Data Management Blog and IIUG, explain that IBM and HCL (IT services company based in India) entered a strategic partnership to develop and market Informix products.
As of May 1, HCL will take the development and support of Informix. But until further notice nothing changes from a customer perspective as IBM remains the first point of contact for any customer interaction.
Further information should be provided in the near future, in particular this will be an hot topic in the upcoming IIUG 2017 conference to start this weekend.

This is not the first time that IBM and HCL get into a similar deal. Last year the same happened with Tivoli Workload Automation and a few Rational products.

Versão Portuguesa
Uma declaração de Dan Hernandez, VP Offering Management Analytics, disponível no IBM Data Management Blog e IIUG, explica que a IBM e a HCL (companhia de serviços de IT baseada na India) estableceram uma parceria estratégica para desenvolver e comercializar os produtos Informix.
Em 1 de Maio, a HCL assumirá o desenvolvimento e suporte do Informix. Mas até mais desenvolvimentos nada mudará na perspectiva dos clientes, visto que a IBM permanece como o primeiro ponto de contato para qualquer interação com os clientes.
Mais informação deverá ser fornecida num futuro próximo, em particular este deverá ser um tema quente da próxima conferência do IIUG (2017) a começar no próximo fim de semana.

Esta não é a primeira vez que a IBM e a HCL iniciam uma cooperação deste tipo. No ano passado o mesmo se passou com o Tivoli Workload Scheduler e alguns produtos Rational.

12.10.xC8 and rolling upgrades / 12.10.xC8 e rolling upgrades

2016-12-13T22:31:00.000+00:00

Something in english about the article (original version here: http://informix-technology.blogspot.com/2016/12/1210xc8-and-rolling-upgrades-1210xc8-e.html)

English version
IBM published an alert (http://www.ibm.com/support/docview.wss?uid=swg21995897) stating that the lastest 12.10 fixpack (xC8) does not support the rolling upgrades feature. A rolling upgrade is the functionality that allows us to upgrade the secondary servers without having to restore them. This is supported only from version major.minor.xCn to major.minor.xCn+1 and when the fixpack does not change physical data structures. Unfortunately that's not the case with 12.10.xC8 as it was needed to make some internal changes to support encryption at rest (EaR).
As such it is clear that rolling upgrades can't be used to upgrade to 12.10.xC8, but that apparently was not clear on the product release notes

Versão Portuguesa
A IBM publicou um alerta (http://www.ibm.com/support/docview.wss?uid=swg21995897) informando que o último fixpack (xC8) da versão 12.10 não suporta a funcionalidade de roling upgrade. O rolling upgrade é o que nos permite fazer um upgrade dos servidores secundários sem ter de restaurar a imagem do primário e re-inicializar a replicação. Isto é suportado apenas entre fixpacks consecutivos (V.v.xCn para V.v.xCn+1 e quando o fixpack não muda estruturas físicas. Infelizmente não é o caso do 12.10.xC8 já que foi necessário mudar algumas estruturas para suportar a encriptação de dbspaces.
Como tal é claro que os rolling upgrades não podem ser usados para passar para a 12.10.xC8, mas aparentemente isso não estava claro nas notas da versão.

String truncate. Column level Encryption / Corte de strings. Encriptação de colunas

2016-12-12T02:00:00.000+00:00

Truncation of strings and it's impact on column level encryption (original version here: http://informix-technology.blogspot.com/2016/12/string-truncate-column-level-encryption.html)

English version
A recent costumer engagement re-activated a dormant issue on my mind... I've already mentioned this is posts, answers in IIUG mailing list, internal and external chats and discussions... Personally I think this is one of the top annoying things in Informix. I'm referring to the fact that on a non-ANSI informix database we truncate a string on insert if it's length exceeds the length of the field. And we do this silently... no error.
There are two RFEs opened for this (appropriately defined as duplicates). The original one is 33830 and the other (duplicate) is 53804. I've seen several reasons for not implementing this, which I'd like to oppose (again):

It's stated in the ANSI standard that it should work like this
Although the ANSI standard is hard to read, there are some paragraphs that seem to suggest this. But even if it's clearly stated there, it isn't what people want. This can corrupt data. Anybody would prefer an error.
Additionally we don't truncate on ANSI mode databases.
We would be changing previous behavior
True. But that could be an option and by default we could keep the old behavior. The author of the RFE suggests a new parameter in $ONCONFIG. That is an option, but I'd prefer also an option on CREATE DATABASE (we already introduced an option for NLSCASE SENSITIVE). Ideally we would have a new ALTER DATABASE to change it. The $ONCONFIG parameter could and should be used to set the default (if the option was not specified on the CREATE DATABASE statement).
I would not create a new $ONCONFIG parameter. I'd prefer having more options on the EILSEQ_COMPAT_MODE parameter which already controls functionality around the same topic.
It would be hard to implement
Having basic programming knowledge and considering we don't do this for ANSI mode databases (see test below), I doubt this would be too hard to implement. Somehow I can imagine a piece of current code like

if ( ANSI_MODE_FLAG && length(input) > col_length)
raise_exception(1279);

which would become:

if ((ANSI_MODE_FLAG || AVOID_TRUNCATE_FLAG) && length(input) > col_length)
raise_exception(1279);

ANSI_MODE_FLAG and AVOID_TRUNCATE_FLAG are assumed to be flags set from the logging mode and from the database (or session) options
That's not a database problem. The application must check it's inputs
Although I can agree with the idea that applications should check the inputs, I know many of them don't check the length. And as we don't silently truncate a big number (100000 for example) when inserted into a SMALLINT column, I can't understand why we do it with strings. The database must help keeping data integrity. And it fails doing that for strings

As mentioned before we don't truncate strings on ANSI mode database. Here's what happens:


castelo@primary:informix-> dbaccess -e stores_ansi test_ansi_truncate.sql

Database selected.

DROP TABLE IF EXISTS test;
Table dropped.


CREATE TABLE test
(
        col1 CHAR(5)
);
Table created.



INSERT INTO test VALUES('123456');
 1279: Value exceeds string column length.
Error in line 7
Near character position 32


  377: Must terminate transaction before closing database.

  853: Current transaction has been rolled back due to error 
or missing COMMIT WORK.

castelo@primary:informix->

Why don't we simply use ANSI mode databases? Well... They have other limitations (can't use datablades) and conversion of existing ones would require application changes.

Ok... so string truncation is a problem by itself. But this article is about a specially complex and nasty effect of string truncation.
Users looking into column level encryption will notice that the encrypted form of the data will be stored in a character column. And the encryption process will "enlarge" the length of the data. Even more complex, the length of encrypted data depends on various factors. The initial number of "characters" (or digits) is one. Others are if it uses hint or not and the encryption algorithm. Below is a table from the manual that maps the "N" original digits/characters to the final result depending on the algorithm and usage of the hint:

N	ENCRYPT_TDES No Hint	ENCRYPT_AES No Hint	ENCRYPT_TDES With Hint	ENCRYPT_AES With Hint
1 to 7	35	43	87	99
8 to 15	43	43	99	99
16 to 23	55	67	107	119
24 to 31	67	67	119	119
32 to 39	75	87	131	139
40 to 47	87	87	139	139
100	163	171	215	227
200	299	299	355	355
500	695	707	747	759

The previous values can be calculated using the following formulae (again, accordingly to the manual):

Encryption by ENCRYPT_TDES( ) with no hint:
Encrypted size = (4 x ((8 x((N + 8)/8) + 10)/3) + 11)
Encryption by ENCRYPT_AES( ) with no hint:
Encrypted size = (4 x ((16 x((N + 16)/16) + 10)/3) + 11)
Encryption by ENCRYPT_TDES( ) with a hint:
Encrypted size = (4 x ((8 x((N + 8)/8) + 50)/3) + 11)
Encryption by ENCRYPT_AES( ) with a hint:
Encrypted size = (4 x ((16 x((N + 16)/16) + 50)/3) + 11)

The integer division ( / ) returns an integer quotient and discards any remainder.

So, effectively, using the above calculations it should be possible to validate if the value inserted by the user would fit a specific column length. But that would have to be implemented for each column. Could introduce some errors, and would make it impossible to implement column level encryption without changing the application, which is otherwise almost possible (the only change is to provide a password at the session level, if that fits the use case).

And after all this discussion, what is the problem in truncating the strings in this context? Pretty simply it will make it impossible to decrypt the data, so effectively it corrupts data in an unrecoverable way. There's no way to overstate this. An application, application developer or a DBA cannot afford to have that risk. As I usually say when I'm discussing this, if we loose a few characters of a name, email address, or street address, it's possible that a human can recover the missing data by looking at what is left. But with column level encryption even the loss of a single character means the data is lost. Not something we want to deal with, or have to explain to business managers.
What can we do? We could start by opening a bunch of PMRs and link them to the RFEs above... but apart from pressing IBM there's actually something very easy we can do to solve this for the very strict context of column level encryption.
As mentioned, recently I had a customer who is concerned with the upcoming EU data protection regulations and is considering their options to address the requirements in that new compliance challenge. One of the options is to use column level encryption, but they were highly concerned with the above scenario. So I gave this matter a considerable thought and I think I came up with a relatively reasonable workaround (although I hate to be forced to deal with this in the first place).

The solution is elegant, relatively lightweight, doesn't require any extra application changes and hopefully should be able to avoid the nasty hypotheses of data loss or corruption.
My first approach was to implement a trigger, and try to verify if the input data would fit the column. I quickly realized that the data as seen by the trigger is already truncated, so the approach would not work. But at that same moment it became clear that another approach would work: If the data is already truncated (or not, depending on the sizes of course), all I had to do was try to decrypt it. If the data was actually truncated, it would raise an error. And if I try that within a trigger, the triggering operation will naturally fail, which if the intended outcome. You can check the code at the end of the article.
Trying to decrypt the data would have the following problems:

It would be expensive in terms of CPU resources
If the data has been encrypted with a specific password passed to the encrypt functions (ENCRYPT_AES() or ENCRYPT_TDES() ), I would not be able to DECRYPT_CHAR(), without knowing the password

A solution to both of this problems is to use the GETHINT() function. It apparently is less expensive than DECRYPT_CHAR and at the same time doesn't require the password. So it will work in either cases (password at session level or password at function level). It will also "work" even if no hint was provided. Most importantly it will fail if data truncation had happened.

So basically I need to create a procedure that receives the encrypted data, apply the GETHINT() and let the magic happen. This procedure should be called from triggers set on the column/table (INSERT and UPDATE) that pass the "new" values as parameter. I choose to use LVARCHAR(32000) as it should cover most use cases. Smart blob encryption was not considered. In those cases we don't have a size limit...
The code is shown at the end of the article. Let's see what happens when we run it:


bica@primary:fnunes-> dbaccess -e stores test_truncate.sql 

Database selected.

DROP TABLE IF EXISTS test_encrypt;
Table dropped.


CREATE TABLE test_encrypt
(
        col1 SERIAL,
        col2 CHAR(43)
);
Table created.



SET ENCRYPTION PASSWORD 'blog_password';
Encryption password set.



DROP PROCEDURE IF EXISTS check_encryption;
Routine dropped.


CREATE PROCEDURE check_encryption(str LVARCHAR(32000))
        DEFINE dummy CHAR(32);;

        SELECT GETHINT(str) INTO dummy FROM sysmaster:sysdual;;
END PROCEDURE;
Routine created.

;

CREATE TRIGGER i_test_encrypt INSERT ON test_encrypt REFERENCING NEW AS new_data
FOR EACH ROW
(
        EXECUTE PROCEDURE check_encryption(new_data.col2)
);
Trigger created.



CREATE TRIGGER u_test_encrypt UPDATE OF col2 ON test_encrypt REFERENCING NEW AS new_data
FOR EACH ROW
(
        EXECUTE PROCEDURE check_encryption(new_data.col2)
);
Trigger created.



INSERT INTO test_encrypt VALUES(0, ENCRYPT_AES('Row 1'));
1 row(s) inserted.


INSERT INTO test_encrypt VALUES(0, ENCRYPT_AES('Row 2'));
1 row(s) inserted.

 

INSERT INTO test_encrypt VALUES(0, ENCRYPT_AES('This longer row will probably not fit!'));
26005: The encrypted data is wrong or corrupted.
Error in line 32
Near character position 1


UPDATE test_encrypt SET col2 = ENCRYPT_AES('This longer row will probably not fit!') WHERE col1 = 1;
26005: The encrypted data is wrong or corrupted.
Error in line 34
Near character position 1

UPDATE test_encrypt SET col2 = ENCRYPT_AES('This fits!') WHERE col1 = 2;
1 row(s) updated.



Database closed.

bica@primary:fnunes->

So, as can be seen, I created a table with a column (col2) defined as CHAR(43) which won't be enough for some data I'll try to INSERT/UPDATE.
Then I setup the session encryption password. I create the procedure and the triggers on the table.
And I move on to the DML. The first two INSERTs use short values and they work. The third INSERT uses a longer string which encrypted version won't fit col2. It raises an error 26005. Then I try a similar string but within an UPDATE and I face the same error. And an update with short length works.

I believe this is a simple, clean and robust solution for this problem. But as usual, use it at your own risk. And don't forget this is a workaround for a specific scenario (column level encryption) to overcome a problem I believe should not exist in the first place.

Versão Portuguesa
Uma visita recente a um cliente reavivou um assunto que andava adormecido na minha mente... Já mencionei isto em artigos, respostas na lista de discussão do IIUG, conversas e discussões internas e externas... Pessoalmente penso que é uma das coisas mais irritantes no Informix. Refiro-me ao facto de que numa base de dados não-ANSI, o Informix corta strings na inserção e alteração se o comprimento das mesmas exceder o tamanho da coluna. E tal acontece de forma silenciosa. Sem erro.
Existem dois RFEs abertos para isto (apropriadamente detetados como duplicados). O original é o 33830 e o outro (duplicado) é o 53804. Já me foram sugeridas várias razões para a não implementação disto, as quais uma vez mais gostaria de refutar:

É referido que o standard ANSI sugere que este é o comportamento correto
Embora o standard ANSI seja difícil de ler, existem alguns parágrafos que parecem sugerir isto. Mas mesmo que fosse claro, existem contra-argumentos para isto. Ainda que seja o standard, não é o que as pessoas querem. Isto pode corromper dados. Qualquer pessoa preferirá um erro. Adicionalmente e paradoxalmente nós não fazemos o corte em bases de dados criadas em modo ANSI
Estaria a mudar-se o comportamento anterior
Verdade. Mas isto poderia ser uma opção e por omissão manter-se o comportamento antigo. O autor do RFE sugere um parâmetro no $ONCONFIG. Seria uma opção, mas eu preferiria também uma opção no CREATE DATABASE (já introduzimos uma opção para NLSCASE SENDITIVE). Idealmente deveríamos também ter um novo ALTER DATABASE para mudar a opção. O parâmetro do $ONCONFIG poderia e deveria ser usado como a definição por omissão (se a opção não fosse especificada no CREATE DATABASE).
Pessoalmente não criaria um novo parâmetro, mas antes daria novos valores possíveis ao parâmetro EILSEQ_COMPAT_MODE, que já controla funcionalidades em torno deste tópico
Seria difícil de implementar
Tendo conhecimentos básicos de programação, e considerando que já hoje nós não cortamos as strings em bases de dados criadas em modo ANSI (ver o teste abaixo), duvido que isto fosse muito complexo de implementar. De alguma forma imagino um pedaço de código atual semelhante a:

if ( ANSI_MODE_FLAG && length(input) > col_length)
raise_exception(1279);

que deveria tornar-se:

if ((ANSI_MODE_FLAG || AVOID_TRUNCATE_FLAG) && length(input) > col_length)
raise_exception(1279);

ANSI_MODE_FLAG é assumido que será uma flag dependente do mode de logging da base de dados e AVOID_TRUNCATE_FLAG seria dependente da opção de criação da base de dados ou do parâmetro no $ONCONFIG
Isto não é um problema de base de dados. A aplicação tem de validar os seus inputs
Embora tenha de concordar com a ideia que as aplicações devem validar os seus inputs, sei que muitas delas não verificam o comprimento das strings ou fazem-no pelas definições de estruturas de dados. E se não cortamos de forma silenciosa um número grande (como 100000) ao tentar inserir num SMALLINT, não consigo entender porque o fazemos com strings. A base de dados tem como função essencial assegurar a integridade dos dados, de acordo com as definições dos mesmos. E falha quando se trata de o fazer em strings.

Como mencionado acima, nós não cortamos strings em bases de dados criadas em modo ANSI. Vejamos o que acontece:


castelo@primary:informix-> dbaccess -e stores_ansi test_ansi_truncate.sql

Database selected.

DROP TABLE IF EXISTS teste;
Table dropped.


CREATE TABLE teste
(
        col1 CHAR(5)
);
Table created.



INSERT INTO teste VALUES('123456');
 1279: Value exceeds string column length.
Error in line 7
Near character position 32


  377: Must terminate transaction before closing database.

  853: Current transaction has been rolled back due to error 
or missing COMMIT WORK.

castelo@primary:informix->

Porque não passamos simplesmente a usar bases de dados em modo ANSI? Bem.... têm outras limitações (não podem usar datablades) e isso requereria mudanças no código das aplicações.

Ok... Então o corte de strings é um problema em si mesmo. Mas este artigo é sobre um efeito complexo e devastador desse corte.
Utilizadores que estejam a considerar o uso de encriptação de colunas, verificarão que a forma encriptada dos dados deverá ser guardada numa coluna com um tipo de dados alfa-numéricos (CHAR ou uma variante). E saberão também que o processo de encriptação fará "crescer" o tamanho dos dados. Ainda mais complicado, o tamanho dos dados encriptados dependerá de vários fatores: O número de caracteres (alfa-numéricos) originais é um desses fatores. Outros serão se se usa ou não uma hint, e o algoritmo de encriptação. Abaixo está uma tabela retirada do manual que mapeia o número original de dígitos / caracteres com o tamanho final, dependendo do algoritmo usado e da utilização ou não de hint:

N	ENCRYPT_TDES No Hint	ENCRYPT_AES No Hint	ENCRYPT_TDES With Hint	ENCRYPT_AES With Hint
1 to 7	35	43	87	99
8 to 15	43	43	99	99
16 to 23	55	67	107	119
24 to 31	67	67	119	119
32 to 39	75	87	131	139
40 to 47	87	87	139	139
100	163	171	215	227
200	299	299	355	355
500	695	707	747	759

Os valores anteriores podem ser calculados com as seguintes fórmulas (de acordo com o manual):

Encriptação com ENCRYPT_TDES( ) sem hint:
Tamanho dados encriptados = (4 x ((8 x((N + 8)/8) + 10)/3) + 11)
Encriptação com ENCRYPT_AES( ) sem hint:
Tamanho dados encriptados = (4 x ((16 x((N + 16)/16) + 10)/3) + 11)
Encriptação com ENCRYPT_TDES( ) com hint:
Tamanho dados encriptados = (4 x ((8 x((N + 8)/8) + 50)/3) + 11)
Encriptação com ENCRYPT_AES( ) com hint:
Tamanho dados encriptados= (4 x ((16 x((N + 16)/16) + 50)/3) + 11)

A divisão inteira ( / ) retorna um quociente inteiro descartando qualquer resto.

Portanto, efetivamente usando os cálculos acima deverá ser possível validar se um valor inserido por um utilizador caberá numa determinada coluna depois de encriptado. Mas isto teria de ser implementado para cada coluna. Poderia introduzir alguns erros, e tornaria impossível implementar a encriptação de colunas sem mudar a aplicação, o que de outra forma seria praticamente possível (a única alteração necessária seria o providenciar uma password de encriptação ao nível de sessão, se tal for permitido pelo caso de uso).

E depois de toda esta discussão, qual é o problema em cortar strings neste contexto? Muito simplesmente, tornará impossível efetuar a desencriptação, pelo que efetivamente tal situação corrompe dados de forma irrecuperável. Não há forma de exagerar esta conclusão. Uma aplicação, um programador ou um DBA não podem dar-se ao luxo de correr esse risco. Como habitualmente digo quando estou a discutir este assunto, se perdermos uns poucos caracteres de um nome, um endereço de correio ou endereço postal, é possível que um ser humano possa recuperar os dados cortados através da consulta do que sobrou. Mas com encriptação de colunas, mesmo a perda de um só carater implica que os dados estejam perdidos. Não é coisa com que queiramos lidar ou que tenhamos de explicar a pessoas responsáveis pelo negócio.
Então o que podemos fazer? Podíamos começar por abrir um rol de PMRs e ligá-los a este RFE acima., mas para além de pressionarmos a IBM, existe algo que efetivamente podemos fazer para resolver o contexto estrito de encriptação de colunas.
Como mencionado, recentemente tive contacto com um cliente que está preocupado com a nova regulação de proteção de dados da EU e está a considerar as opções que têm neste novo desafio de compliance. Uma das opções que têm é usar encriptação do nível da coluna, mas estavam altamente preocupados com o cenário acima. Por causa disso dediquei um considerável esforço ao tema e penso que cheguei a uma forma de contornar o problema (embora odeie ter de lidar com tal situação).

A solução é elegante, relativamente leve, não requer nenhuma modificação na aplicação e espero que esteja à altura de evitar a terrível hipótese de perda de dados ou corrupção.

A minha primeira abordagem foi implementar um trigger e tentar verificar se os dados de input (encriptados) caberiam na coluna. Rapidamente me apercebi que o trigger já vê os dados "cortados", pelo que a abordagem não resultaria. Mas no mesmo momento ficou claro que outra abordagem semelhante resultaria: se os dados já estão potencialmente "cortados", tudo o que deveria fazer seria desencriptá-los. Se tivessem sido efetivamente cortados isto despoletaria um erro. E se tal acontecer dentro de um trigger então a operação que despoletou o trigger iria por arrasto falhar. Pode verificar o código no final do artigo. Tentar desencriptar os dados levantaria os seguintes problemas::

Seria dispendioso em termos de recursos de CPU
Se os dados tivessem sido encriptados com uma password especifica passada às funções de encriptação (ENCRYPT_AES() or ENCRYPT_TDES() ), não seria capaz de efetuar a desencriptação sem saber a password

A solução para ambos estes problemas é usar a função GETHINT(). Deverá ser menos exigente em termos de CPU que a DECRYPT_CHAR() e tem a vantagem de não necessitar de password. Deverá portanto funcionar em ambos os casos (passwords ao nível da sessão e ao nível das funções). Irá também funcionar mesmo que não tenha sido utilizada nenhuma hint. Mas o verdadeiramente importante é que falhará se os dados tiverem sido corrompidos.

Assim, basicamente o que necessito é criar um procedimento que recebe os dados encriptados e aplica o GETHINT(), e deixar a magia acontecer. O procedimento deve ser chamado por triggers definidos na coluna / tabela (INSERT e UPDATE), que passam os "novos" valores como parâmetro
Escolhi o LVARCHAR(32000) como tipo do parâmetros dado que deverá cobrir a maioria dos casos. A encriptação de Smart Blobs não foi considerada. Até porque nesses casos não temos um limite de tamanho...
O código está visível no final do artigo. Vejamos o que acontece quando o corremos:


bica@primary:fnunes-> dbaccess -e stores test_truncate.sql 

Database selected.

DROP TABLE IF EXISTS test_encrypt;
Table dropped.


CREATE TABLE test_encrypt
(
        col1 SERIAL,
        col2 CHAR(43)
);
Table created.



SET ENCRYPTION PASSWORD 'blog_password';
Encryption password set.



DROP PROCEDURE IF EXISTS check_encryption;
Routine dropped.


CREATE PROCEDURE check_encryption(str LVARCHAR(32000))
        DEFINE dummy CHAR(32);;

        SELECT GETHINT(str) INTO dummy FROM sysmaster:sysdual;;
END PROCEDURE;
Routine created.

;

CREATE TRIGGER i_test_encrypt INSERT ON test_encrypt REFERENCING NEW AS new_data
FOR EACH ROW
(
        EXECUTE PROCEDURE check_encryption(new_data.col2)
);
Trigger created.



CREATE TRIGGER u_test_encrypt UPDATE OF col2 ON test_encrypt REFERENCING NEW AS new_data
FOR EACH ROW
(
        EXECUTE PROCEDURE check_encryption(new_data.col2)
);
Trigger created.



INSERT INTO test_encrypt VALUES(0, ENCRYPT_AES('Row 1'));
1 row(s) inserted.


INSERT INTO test_encrypt VALUES(0, ENCRYPT_AES('Row 2'));
1 row(s) inserted.

 

INSERT INTO test_encrypt VALUES(0, ENCRYPT_AES('This longer row will probably not fit!'));
26005: The encrypted data is wrong or corrupted.
Error in line 32
Near character position 1


UPDATE test_encrypt SET col2 = ENCRYPT_AES('This longer row will probably not fit!') WHERE col1 = 1;
26005: The encrypted data is wrong or corrupted.
Error in line 34
Near character position 1

UPDATE test_encrypt SET col2 = ENCRYPT_AES('This fits!') WHERE col1 = 2;
1 row(s) updated.



Database closed.

bica@primary:fnunes->

Como se pode ver, crio uma tabela com uma coluna (col2) definida como CHAR(43) e que não será suficiente para alguns dados que irei tentar inserir/alterar.
Depois estabeleço a password de sessão. Crio o procedimento e os triggers na tabela. E passo ao DML. Os primeiros dois INSERTs usam valores curtos e vão funcionar. O terceiro INSERT usa uma string mais longa, cuja versão encriptada não cabe na coluna col2. Despoleta um erro 26005. Depois tento uma string semelhante mas via um UPDATE e encontramos o mesmo erro. Depois um UPDATE "curto" e funciona
Acredito que isto é simples, "limpo" e robusto para resolver o problema. Mas como é habitual, utilize por sua conta, peso e risco. E relembro que isto é uma forma de contornar um problema que penso que nunca deveria ter acontecido, num contexto específico que é a encriptação de colunas.

Code/Código


DROP TABLE IF EXISTS test_encrypt;
CREATE TABLE test_encrypt
(
        col1 SERIAL,
        col2 CHAR(43)
);

SET ENCRYPTION PASSWORD 'blog_password';

DROP PROCEDURE IF EXISTS check_encryption;
CREATE PROCEDURE check_encryption(str LVARCHAR(32000))
        DEFINE dummy CHAR(32);

        SELECT GETHINT(str) INTO dummy FROM sysmaster:sysdual;
END PROCEDURE;

CREATE TRIGGER i_test_encrypt INSERT ON test_encrypt REFERENCING NEW AS new_data
FOR EACH ROW
(
        EXECUTE PROCEDURE check_encryption(new_data.col2)
);

CREATE TRIGGER u_test_encrypt UPDATE OF col2 ON test_encrypt REFERENCING NEW AS new_data
FOR EACH ROW
(
        EXECUTE PROCEDURE check_encryption(new_data.col2)
);

INSERT INTO test_encrypt VALUES(0, ENCRYPT_AES('Row 1'));
INSERT INTO test_encrypt VALUES(0, ENCRYPT_AES('Row 2'));

INSERT INTO test_encrypt VALUES(0, ENCRYPT_AES('This longer row will probably not fit!'));

UPDATE test_encrypt SET col2 = ENCRYPT_AES('This longer row will probably not fit!') WHERE col1 = 1;
UPDATE test_encrypt SET col2 = ENCRYPT_AES('This fits!') WHERE col1 = 2;

Informix 12.10.xC8 is out! / Informix 12.10.xC8 saíu!

2016-12-06T01:00:00.000+00:00

What's new in Informix 12.10.xC8 fixpack (original version here: http://informix-technology.blogspot.com/2016/12/informix-1210xc8-is-out-informix.html)

English version
And a new fixpack sees the daylight! This time is version 12.10.xC8. Contrary to the previous one, I think this one brings some exciting news. As usual here's the official list from the documentation but with my own comments:

Migration

Server changes that affect migration
A new $ONCONFIG parameter (DISK_ENCRYPTION) was introduced
A new session environment variable (USE_SHARDING) was introduced
A new environment variable (IFX_LO_READONLY) was introduced
This fixpack will force some internal structures migration. In order to go back, reversion (onmode -b) must be used

Administration

View and rerun DB-Access commands
DBAccess now has a new option (-history) which can be used in non-menu mode, so that the commands run are labeled with a number, which makes it easier to re-run a previously entered command (run #). A list of commands and their numbers can be retunred by "history"

JSON compatibility

Consistent sharded insert, update, and delete operations
When operating with a sharded collection, when we inserted a row that wouldn't belong to the cluster node we were connected to, the record would be moved asynchronously to the correct server. Now we can configure the session so that the servers move the object synchronously (two phase commit) before returning the COMMIT.
Complex text search with regular expressions
We finally introduced the regular expression capabilities in the engine. This is a new auto-register datablade (we used to have a non-official bladelet before). It works in MongoDB API and in normal SQL by introducing a few new functions like regexp_match(), regexp_split etc.
JSON compatibility enhancements
Several improvements in MongoDB API clients:

They can use native cursors which makes it perform better on "pagination" queries. Previously the client would need to issue a new query each time
The cursors above will have a timeout so that they won't keep opened after the user idles for too long
New option to close idle connections on JSON listener
A new listener parameter (listener.http.headers.size.maximum) allows controlling the maximum size of incoming HTTP headers

Enterprise replication

Consistent sharded insert, update, and delete operation
Same as above but for traditional tables
List Enterprise Replication definition commands
New "cdr list catalog" command will retrieve the CDR commands needed do duplicate current environment (for testing, or move to production)

Application development

Rename system-generated indexes
A system generated index is an index automatically created by Informix to support a primary key, unique or foreign key constraint. If we remove the constrain the index is automatically removed. These indexes are distinguished from standard ones because their name starts with a " " (space).
We now have the chance to rename these indexes which brings two advantages:

We may want to standardize the indexes name
We may want to remove the constraint but keep the index (which will make it faster if we want to re-implement the constraint)

Temporary table space usage
One of my favorite. Is was nearly impossible to retrieve the session ID associated with temporary objects in the temporary dbspaces (I recently created a script called ixtempuse to overcome this). A new column (SID) was created in sysptnhdr. The column will be populated for temporary objects like hash tables, sort structures, view materialization structures etc. So, from now on it will be trivial to identify the session(s) consuming all of the temporary space
Suspend validation of check constraints
Just like foreign key constraints, the check constraints now accept the "no validate" clause. This is very important in the following scenarios:

When importing data, we know it should be ok
Informix will verify that the data in the table being attached to a fragmented table (as a new fragment) validates the expression or list/interval that it used for the fragmentation scheme. This can be time consuming during the execution of ALTER FRAGMENT ATTACH as it forces a full scan of the consumed table. A solution for this would be to create a check constraint in the new table before the ATTACH. This would still consume resources and time, but it wouldn't be blocking anything. Now, with the new feature, we can make those check constraints instantaneous and then the engine can use them to skip the full scan!

JDBC 4.0 compliance
We finally improved the Informix native driver compatibility with the JDBC standard. I've been thinking that having "native" and DRDA drivers puts Informix in a tricky situation: On one hand the DRDA drivers are easily updated because they're used by several databases. This makes them a preferable choice. But they don't support all the Informix specific functionality and in order to fix that the DRDA protocol would probably require changes. Being an open standard makes it difficult. It's nice to see investment in the native drivers.
Query smart large objects with read-only access
An application can open smart blobs in read-only mode, which avoids the locking overhead that otherwise would be required

Security

Encrypt storage spaces
From this fixpack onward we will be able to use transparent data encryption at the dbspace level. I won't go into high details, but this encryption is totally transparent for the application and database administrators. It intends to protect the database data from system administrators and possible disk copying or theft or privacy issues arising from old disk disposal. The way it works is pretty simple. After configuring a new parameter (DISK_ENCRYPTION) with a name of a keystore, any new dbspace will be encrypted by default. There's an option if you want to create a non encrypted dbspace.
Encryption of existing dbspaces can be done by backup/restore. Decryption of already encrypted dbspaces can also be done by backup/restore. Each dbspace will use it's own encryption key. Space usage will not increase. Encryption of a table or set of tables can be achieved by moving it to an encrypted dbspace.

Time series

Advanced analytic for time series data
New functions to analyze time series data for patterns or abnormalities including quantify similarity, distance, and correlation between two sequences
Enhancements to time series functions
Several improvements on what can be used in expressions for CountIf and Apply functions

Embeddability

Easier embedded deployment
ifxdeploy can be used by non-root users and the configuration file is deprecated in favor of command line parameter that were extended.

In global it seems a very promising fixpack (much more interesing than the latest one). Besides all the improvements in the NoSQL areas, it includes a series of important improvements for the common user, like disk encryption, better JDBC compatibility and regular expressions as SQL functions. And naturally it includes bug fixes.

[EDIT 2016-12-13]
Accordingly to an alert from IBM (http://www.ibm.com/support/docview.wss?uid=swg21995897) this fixpack does NOT support rolling upgrades. This isn't a surprise as it changes some internal page structures and by definition no fixpack that does that supports rolling upgrade. But It's better to make it clear

Versão Portuguesa
E um novo fixpack vê a luz do dia! Desta feita é a versão 12.10.xC8. Contrariamente ao anterior penso que este traz novidades muito interessantes. Como habitualmente aqui está a lista oficial mas com os meus comentários:

Migração

Mudanças no servidor que afetam a migração
Introdução de um novo parâmetro do $ONCONFIG (DISK_ENCRYPTION)
Introdução de uma nova variável de sessão (USE_SHARDING)
Introdução de uma nova variável de ambiente (IFX_LO_READONLY)
Este fixpack força mudanças na estrutura interna. Para voltar atrás será necessário efetuar uma reversão (onmode -b)

Administração

Ver e re-executar comandos do DBAccess
O dbaccess tem agora uma opção (-history) que pode ser usada em modo direto (sem menus). Esta opção faz com que os comandos executados sejam numerados, para mais fácil re-execução de um comando anterior (run #). A lista de comandos já executados e o seu respetivo número pode ser obtida com o comando "history"

Compatibilidade JSON

Operações (INSERT/UPDATE/DELETE) em shards de forma consistente
Quando trabalhamos com uma sharded collection, e inserimos uma linha que deverá pertencer a outro nó que não aquele a que estamos ligados, o registo deveria ser movido para o destino de forma assíncrona para o servidor correto. Agora, se assim o desejarmos, podemos pedir que a movimentação seja síncrona (two phase commit) e só então nos seja retornado o COMMIT
Pesquisa de texto utilizando expressões regulares
Finalmente introduzimos as funcionalidades dadas pelas expressões regulares no motor. Trata-se de um novo datablade que se auto-regista quando usamos as suas funções pela primeira vez (já existia um bladelet não oficialmente suportado). Funciona no MongoDB API e em SQL normal, com a introdução de uma série de funções como regexp_match(), regexp_split() etc.
Melhorias de compatibilidade JSON
Várias novidades em clientes MongoDB API:

Podem utilizar cursores nativos, o que permite maior eficiência em queries para efetuar paginação. Anteriormente o cliente teria de enviar uma query para cada página
Os cursores referidos anteriormente têm um timeout para evitar que fiquem abertos mesmo após longos períodos de inatividade dos clientes
Nova opção para fechar conexões inativas no listener de JSON
Um novo parâmetro do listener (listener.http.headers.size.maximum) permite controlar o tamanho máximo dos cabeçalhos dos pedidos HTTP recebidos

Enterprise replication

Operações (INSERT/UPDATE/DELETE) em shards de forma consistente
Como a nota anterior para sharded collections, mas para tabelas tradicionais
Listar comandos de Enterprise Replication
Novo comando "cdr list catalog" permite obter uma lista de comandos CDR necessária para duplicar o ambiente corrente (para testes ou cópia para produção)

Desenvolvimento aplicacional

Renomear índices gerados pelo sistema
Um índice gerado automaticamente pelo sistema é um índice criado pelo Informix para suportar uma constraint como chave primária, chave estrangeira, ou unique constraint.
Se removermos a constraint o índice é automaticamente eliminado. Estes índices distinguem-se dos normais porque o seu nome começa com um " " (espaço).
Agora temos a possibilidade de renomear estes índices o que tem duas vantagens:

Podemos querer standardizar os nomes dos índices
Podemos querer remover a constraint mas manter o índice (o que tornará mais rápida a recriação da constraint se for essa a intenção)

Utilização de espaço temporário
Uma das minhas favoritas! Era quase impossível obter a identificação das sessões que estavam a consumir espaço temporário na instância. Recentemente criei um script chamado ixtempuse para contornar essa dificuldade). Agora foi adicionada uma nova coluna (SID) à view da sysmaster chamada sysptnhdr. A coluna será preenchida para objetos temporários como hash tables, sorts, materialização de views etc. Portanto a partir deste fixpack será trivial obter a informação de que sessão(ões) está a consumir espaço temporário.
Suspender a validação de check constraints
Tals como as chaves estrangeiras, agora as check constraints também aceita a cláusula "no validate". Isto é muito importante nos seguintes cenários:

Quando importamos dados e sabemos que os mesmos estão corretos
O Informix verifica que os dados de uma tabela que está a ser adicionada como fragmento de uma tabela fragmentada/particionada, validam a expressão de fragmentação em uso.
Isto pode consumir muito tempo e recursos durante a execução da instrução ALTER FRAGMENT ATTACH, dado que força um full scan na tabela que é consumida. Uma solução para isto era criar uma check constraint na tabela que vamos adicionar que correspondesse à expressão de fragmentação. O otimizador tem inteligência para detetar a relação e evitar a verificação (dado que a constraint já o garante). Isto evita o tempo durante o ATTACH, mas implicava gastar os recursos na validação quando se criava a constraint. Ora agora com o "no validate" podemos criar a constraint instantaneamente, e evitar por completo o desperdício de tempo. Claro que a responsabilidade de garantir que os dados carregados estão corretos fica inteiramente a cargo do utilizador.

Conformidade com JDBC 4.0
Finalmente melhoramos a compatibilidade do driver nativo com o standard JDBC. Eu penso que termos drivers nativos e DRDA coloca o Informix numa situação delicada: Por um lado os drivers DRDA estão mais adequados aos vários standards e são mais frequentemente atualizados pois podem ser usados em várias bases de dados da IBM. Mas por outro lado não suportam algumas funcionalidades específicas do Informix e para corrigir isto o standard DRDA teria de ser modificado. Sendo um standard aberto isto não é fácil. Por isso é muito bom ver investimento feito nos drivers nativos.
Acesso a smart large objects em modo de leitura apenas
Uma aplicação pode optar por abrir smart large objects apenas em modo de leitura o que evita a sobrecarga que a gestão de locks traz.

Segurança

Encriptação de ficheiros de dados
A partir deste fixpack poderemos usar encriptação de dados transparente ao nível dos dbspaces. Não irei entrar em detalhes muito técnicos, mas esta encriptação é totalmente transparente para as aplicações e utilizadores da base de dados. Destina-se a proteger os dados de administradores de sistema e possíveis cópias ou roubos de disco ou de problemas de privacidade levantados pela descontinuação de uso de discos antigos.
A forma como funciona é muito simples. Após configurar um novo parâmetro (DISK_ENCRYPTION) com o nome de uma keystore, qualquer dbspace novo será encriptado. Existe uma opção para os criar sem encriptação.
A encriptação de dbspaces já existentes pode ser alcançada através de backup/restore. Desencriptação de dbsapces já encriptados pode ser obtido da mesma forma.
Cada dbspace terá a sua própria chave de encriptação. O espaço ocupado não crescerá por via da encriptação. Encriptação de uma tabela ou conjunto de tabelas específico pode ser conseguido pela movimentação das mesmas para um dbspace encriptado

Time series

Analítica avançada sobre dados timeseries
Novas funções para analisar dados timeseries, como pesquisa de padrões ou anormalidades, incluindo quantificação de similaridade, distância e correlação entre duas sequências
Melhorias em funções de timeseries
Várias melhorias no que pode ser usado como expressões para as funções CountIF e Apply

Embeddability

Distribuição "embebida" mais fácil
O ifxdeploy pode ser usado como non-root e o seu ficheiro de configuração foi descontinuado em favor de parâmetros na linha de comandos, que foram expandidos

Vendo na globalidade parece-me um fixpack bastante promissor (e bem mais interessante que o último). Para além das melhorias na área do NoSQL, existem várias melhorias importantes para o utilizador comum, como a encriptação de disco, melhor compatibilidade JDBC, verificação de uso de espaço temporário e expressões regulares em funções SQL. E naturalmente uma série de correções de bugs como em qualquer fixpack.

[EDITADO 2016-12-13]
Segundo um alerta da IBM (http://www.ibm.com/support/docview.wss?uid=swg21995897) este fixpack NÃO suporta rolling upgrades. Isto não é uma surpresa pois muda algumas estruturas nas páginas, e por definição nenhum fixpack que o façao suporta rolling upgrade. Mas é melhor deixar isto bem claro.

Informix functionality demo / Demo de funcionalidades Informix

2016-12-05T01:00:00.000+00:00

If you want to see the power and versatility of Informix, check the video mentioned in this post (original version here: http://informix-technology.blogspot.com/2016/12/informix-functionality-demo-demo-de.html)

English version
Very recently a new video about Informix functionality was made available. I usually don't post about such events, but this video is not a customer endorsing Informix as usual. It's a long time Informix consultant and IT specialist, author of several Informix related books (one of which I have the honor of owning a signed copy), Carlton Doe, leading us through several Informix features.. In around 17m you'll be able to check several innovative features of Informix in a potential real use case. From IoT, platform diversity, replication, ease of use and integration in modern environments you'll be able to see it all...

Check below!

Versão Portuguesa
Muito recentemente um novo vídeo sobre funcionalidades do Informix foi disponibilizado. Normalmente não publico nada sobre este tipo de eventos, mas este vídeo não é de um cliente ou parceiro a louvar o Informix. É um consultor e especialista de TI, autor de vários livros sobre Informix (oum dos quais tenho a honra de possuir uma cópia autografada), Carlton Doe, guiando-nos por várias funcionalidades do Informix. Em cerca de 17m poderá verificar várias funcionalidades inovadoras do Informix num potencial cenário real. De IoT, diversidade de plataformas, replicação, facilidade de utilização e integração em ambientes modernos poderá ver tudo...

Veja abaixo!

INFORMIXDIR and files configuration / INFORMIXDIR e configuração de ficheiros

2016-12-01T16:21:00.002+00:00

Setting up INFORMIXDIR and instance files, specially in a cluster configuration (original version here: http://informix-technology.blogspot.com/2016/11/informixdir-and-files-configuration.html)

English version
Ok... the article title is a bit confusing, but sometimes so is this subject. I've received a few questions about how to setup the Informix related files, in particular if a cluster (active/passive) configuration is being used. Let's start by listing the files I'm referring to

Files or directories we can configure

INFORMIXDIR
The product installation directory. Note that different instances can share a single $INFORMIXDIR
ONCONFIG file
This is the instance configuration file. All the parameters for instance initialization and subsequent startups are contained in this file. This file is pointed to by the environment variable $ONCONFIG, but the variable only specifies the file name. The file location must be $INFORMIXDIR/etc
online.log
This is the instance log file where the instances messages will be written. The file can have the name we want and it's location is defined by an $ONCONFIG parameter (MSGPATH)
SQLHOSTS
This is the file containing the names, addresses, ports, protocols and options of each listener. By default it's $INFORMIXDIR/etc/sqlhosts, but it can be overridden by the value in $INFORMIXSQLHOSTS variable (full PATH)
chunks
The chunks are Informix datafiles. In the good old days, when everybody was using RAW devices, the recommendation used to be creating symbolic links that would point to the raw devices. I still like to do this, even when using cooked files (datafiles in operating system file system). It gives us an extra flexibility in case we need to move the physical files
console file
This file is somehow "ignored" by many customers. It's a file where some messages are written. We don't normally need to check it. The full path is defined by an $ONCONFIG parameter (CONSOLE)
Restore point dir
This is a file system location (directory) where Informix write some information during upgrades. It's defined by an $ONCONFIG parameter (RESTORE_POINT_DIR)
LTAPEDEV/TAPEDEV
These are the locations for logical log backup and instance backups, defined by the $ONCONFIG parameters with the same names. They can be defined with a special value ("/dev/null") if you want/need to discard the objects. Note that LTAPEDEV requires an instance restart if we're changing it to/from "/dev/null". Normally they'll point to a directory in the file system (or a file on very old Informix versions). If we're using a storage manager, their value is not really important (unless we're referring to LTAPEDEV and it has the "/dev/null" value - this is not compatible with the use of onbar and a storage manager)
BAR activity log
The onbar activity log. Defined by the $ONCONFIG parameter BAR_ACT_LOG
BAR debug log
The onbar debug log. Only used for debugging and pointed to by the $ONCONFIG parameter BAR_DEBUG_LOG
IXBAR file
The very important file which contains the onbar catalog. This is defined by an $ONCONFIG parameter (BAR_IXBAR_PATH). The default is $INFORMIXDIR/etc/ixbar.N where "N" is the instance SERVERNUM
BAR BSA library path
The full location of the XBSA library we're using, if we setup a storage manager. The location will be dependent on the storage manager Informix client installation. The value is defined in the BAR_BSA_LIBPATH $ONCONFIG parameter
Database Library Path
The location where we allow the engine to load dynamic libraries for extensibility purposes. The location is defined by the $ONCONFIG parameter DB_LIBRARY_PATH
Data Replication lost and found
Base file name for HDR environments to store transactions committed on a primary server that were not successfully transmitted to the secondary server. This is defined by the $ONCONFIG parameter DRLOSTFOUND
Dump directory
The directory where shared memory dumps and diagnostic files will be written. This must be a filesystem location with enough storage for a few shared memory dumps (assuming the instance is configured to create them in case of failure). The location is defined by an $ONCONFIG parameter (DUMPDIR)
Alarmprogram
The script/program to run when certain events happen. The location is defined by an $ONCONFIG parameter (ALARMPROGRAM)
System alarm program
The system alarm program/script. This one is called when serious (crash/assert fails) happen and is defined by an $ONCONFIG parameter (SYSALARMPROGRAM)
Java Virtual Processor log
File that takes trace outputs and stack dumps from the java virtual CPUs. Defined in the $ONCONFIG parameter JVPLOGFILE
ADTCFG file
This is the file controlling the auditing feature. It exists in $INFORMIXDIR/aaodir. After chnages are made the system creates an adtcfg.N where N is the value of SERVERNUM.

Aspects to consider

The INFORMIXDIR

The first thing to consider is the $INFORMIXDIR. Many people usually use /opt/informix, or /usr/informix and install the product there. This is not the best option because when we're planning an upgrade we need to have both the old and the new version available. Some customers solve this by installing the product in a directory that contains the version (let's assume "my" standard) like /usr/informix/srvr1210fc7w1 and then create a symbolic link /usr/informix/server and point it to the version they want to use. This may work for a single instance, but becomes problematic if you use several instances and you want the option to upgrade them at different moments

The existence of a cluster configuration raises another problem. Should you install the product on both nodes, or just in a single cluster controlled path that moves between nodes? There are people who defend the idea of a single INFORMIXDIR installation which is moved to the active node. But again, if you have several instances and you consider spreading them across the two nodes (all in a single node if the hardware fails or needs maintenance) that won't fulfill the requirements. A single $INFORMIXDIR moving between nodes simplifies other issues. If you have an INFORMIXDIR on node A, and an INFORMIXDIR on node B, you'll have two $ONCONFIG, ADTCFGs and maybe a few others that you cannot define their full path.

Another aspect related to this, is that if you configure role separation (a very nice and free Informix feature that allows different people to have different security functions in an Informix instance), if you have a single INFORMIXDIR for several instances, you can't separate the roles differently across the instances. In most cases this would not be an issue. Actually most customers don't have enough people managing the database to be able to separate the roles even for a single instance.

The log files

The log files, like online.log, onbar activity and debug logs etc. sometimes have defaults that are inside $INFORMIXDIR, and even when the defaults are not like that, too often I find customers that put them there. The problem in doing that is simple. When we upgrade, the logs history becomes "broken" because now you have logs inside the old and the new $INFORMIXDIR.

Another obvious problem with logs comes from cluster environments where an instance moves from node A to node B. If the logs are not pointing to a common cluster resource you'll have parts of the logs spread across the nodes.
On the other hand, if the logs are pointing to a common location we loose track of where the instance was started. And for problem analysis this is important (more about this in a later article).

The chunks

The decision here is if we use symbolic links or not. This used to be much more important because sometimes a change in the raw devices would mean a different path. And we couldn't change the path of the chunks as the engine knows them. In modern systems and Informix versions, we can create the raw devices with specific names (so if we need to rebuild or change some options we can re-use the old names) and we can change the path name of the chunks by doing a "fake" external backup/restore with chunk renaming.

The scripts

Usually the instances require a set of scripts maintained by the DBAs. Once again, too many often I see these scripts inside the $INFORMIXDIR, or $INFORMIXDIR/bin. As mentioned earlier, this is not a good practice because during upgrades it would be a mess, and the same happens if you run several instances on the same box and consider having different INFORMIXDIRs (one reason would be that they can be in different versions).

The tricky part is that sometimes the scripts must be customized for each instance. And another problem (again) arises from the use of a cluster environment. In that case you may need to keep as many copies of the scripts as nodes you're running. Eventually, if the cluster allows you to have a common mount point or a cluster filesystem (like GPFS, or GFS/GFS2) you may have a solution. For situations where a single script must have different configurations for different instances, we can use a "case/esac" structure in SHELL conditioned by $INFORMIXSERVER. This is a possibility for example to implement a common alarm program which may need to have different backup configurations for example.

Recommendations

INFORMIXDIR

I usually install the product in locations that clearly indicate the version (/usr/informix/srvr1210fc7w1). But then I use a script (ixvirtdir) to create a "special" INFORMIXDIR for each specific instance. The script takes a few parameters like the existing INFORMIXDIR and the new one which I normally define with a suffix equal to the instance name. Additionally we can provide operating system groups that will be used as DBSA, AAO and DBSSO for role separation. The "special" INFORMIXDIR will be a new directory where inside I'll create a link to each original INFORMIXDIR's sub-directory with a few exceptions. Let's see an example:

castelo@primary:informix-> echo $INFORMIXSERVER $INFORMIXDIR
castelo /opt/informix/srvr1210fc7w1_castelo
castelo@primary:informix-> pwd
/opt/informix/srvr1210fc7w1_castelo
castelo@primary:informix-> ls -l
total 84
drwxrwx--- 2 informix ixaao    4096 Aug 18 02:46 aaodir
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 bin -> /opt/informix/srvr1210fc7w1/bin
drwxrwx--- 2 informix ixdbsso  4096 Aug  1 13:44 dbssodir
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 demo -> /opt/informix/srvr1210fc7w1/demo
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 doc -> /opt/informix/srvr1210fc7w1/doc
drwxrwxr-x 4 informix ixdbsa   4096 Aug 23 11:10 etc
lrwxrwxrwx 1 informix informix   34 Nov 13 03:21 extend -> /opt/informix/srvr1210fc7w1/extend
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 gls -> /opt/informix/srvr1210fc7w1/gls
lrwxrwxrwx 1 informix informix   33 Nov 13 03:21 gskit -> /opt/informix/srvr1210fc7w1/gskit
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 help -> /opt/informix/srvr1210fc7w1/help
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 incl -> /opt/informix/srvr1210fc7w1/incl
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 isa -> /opt/informix/srvr1210fc7w1/isa
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 lib -> /opt/informix/srvr1210fc7w1/lib
lrwxrwxrwx 1 informix informix   35 Nov 13 03:21 license -> /opt/informix/srvr1210fc7w1/license
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 msg -> /opt/informix/srvr1210fc7w1/msg
lrwxrwxrwx 1 informix informix   38 Nov 13 03:21 properties -> /opt/informix/srvr1210fc7w1/properties
lrwxrwxrwx 1 informix informix   35 Nov 13 03:21 release -> /opt/informix/srvr1210fc7w1/release
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 SDK -> /opt/informix/srvr1210fc7w1/SDK
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 snmp -> /opt/informix/srvr1210fc7w1/snmp
drwxrwx--- 3 informix ixdbsa   4096 Aug  1 13:44 ssl
drwxrwx--- 2 informix informix 4096 Aug 23 11:10 tmp

So, INFORMIXDIR is /opt/informix/srvr1210fc7w1_castelo. "castelo" is the INFORMIXSERVER which acts as a suffix. Most sub-directories are just links to the base product installation. The exceptions are "aaodir", "dbssodir", "etc", "ssl" and "tmp". These are real directories for several reasons. In a cluster configuration, the "virtual" INFORMIXDIR would be on a cluster resource and the base product installation would either also be in a cluster resource (single instance on the machine, or if the decision to move to another node would imply move all the instances), or a local product installation. Note that by creating that list of sub-directories as real directories, I'm isolating everything that can vary from one instance to the other. Note also that these sub-directories would not contain very large content, with the possible exception for "tmp" if it's defined as the DUMPDIR for example.
With this method we can achieve maximum flexibility and instance isolation in the following situations:

Several instances on a single machine
Cluster environments even with several instances that don't necessarily move from one node to another as a group
Full role separation at each instance level, allowing for different groups for different instances

Informix user home

The home of the informix user (let's assume /home/informix) will contain two directories: "bin" and "etc". In the "bin" directory I put every script I use for the instances management including the alarmprogram.sh. In the "etc" I put all the configuration scripts/files like:

sqlhosts (single file per machine) facilitates configurations for distributed queries etc.
The configuration file (infx_env.lst) for my script to position across the instances environment (setinfx)
The configuration file for the alarmprogram.sh (alarm_conf.sh) where each instance specific configurations are defined in a case/esac structure

This setup does not solve the cluster problems. In a cluster environment, assuming all the nodes may have some instance(s) running at the same time, this structure must be replicated across nodes. If however you move all the instances as a single block, the /home/informix could be a cluster resource (or at least the two sub-directories - /home/informix/etc and /home/informix/bin ). In any case the "bin" directory must be placed in the PATH environment variable.
We should also try to avoid having two copies of configuration files like $INFORMIXSQLHOSTS, and we may consider using symbolic links to a shared location.

Log files and others

Things like online.log, onbar activity and debug files, ixbar etc should be put on a cluster resource that moves with each instance. On a non cluster environment these files can be created inside a informix's HOME sub-directory like /home/informix/logs and /home/informix/conf.
Even if the files are created inside a cluster resource, specific for each instance I prefer to create the files with a suffix like INFORMIXSERVER (e.g. online_${INFORMIXSERVER}.log, ixbar.${INFORMIXSERVER} etc.
It's important to underline the importance of having a single IXBAR file in the cluster. Otherwise you'll have the catalog information spread across the cluster and it will make the restore process impossible.

Chunks and links

For the chunks I still prefer to use symbolic links. These can point to cooked files or RAW devices. Both the links and the files (RAW or cooked) must be configured as a cluster resource on a cluster environment.

DUMP dirs

There are a few directories that are used sporadically but are very important. One is the configuration of the parameter DUMPDIR where the assert fail files are written. Somehow similar are the parameters RESTORE_POINT_DIR, DRLOSTFOUND and PLOG_OVERFLOW_PATH.
These are important for certain activities, but typically once the issue is solved the files can and are removed. So, it's important that their locations point to large enough and existing directories, but it's not very relevant if they're specific for each instance or a single cluster location.

Versão Portuguesa
OK... o título do artigo é um pouco confuso, mas por vezes também este assunto o é. Tenho recebido algumas questões sobre como configurar os ficheiros usados pelo Informix, em particular num ambiente de cluster (ativo/passivo). Comecemos por enunciar uma lista de ficheiros a que me estou a referir.

Ficheiros ou diretórios que podemos configurar

INFORMIXDIR
O diretório de instalação do produto. Note-se que diferentes instâncias podem partilhar um único $INFORMIXDIR
Ficheiro ONCONFIG
É o ficheiro de configuração da instância. Todos os parâmetros para a inicialização da instância e sub-sequentes arranques estão contidos neste ficheiro. A variável de ambiente $ONCONFIG aponta para o nome do ficheiro, sendo que a sua localização é forçosamente $INFORMIXDIR/etc
online.log
O ficheiro de log onde as mensagens da instância são escritas. O ficheiro pode ter o nome e localização que quisermos e isto é definido pelo parâmetro MSGPATH no $ONCONFIG
SQLHOSTS
O ficheiro que contém os nomes, endereços, portos TCP, protocolos e opções de cada listener. Por omissão a sua localização é $INFORMIXDIR/etc/sqlhosts, mas pode ser redefinido pelo valor da variável de ambiente $INFORMIXSQLHSOSTS (caminho completo)
chunks
Os chunks são os "ficheiros" de dados do Informix. Nos bons velhos tempos em que toda a gente usava dispositivos RAW, a recomendação era utilizar links simbólicos que apontariam para esses dispositivos. Eu ainda gosto desta ideia, mesmo que se utilizem ficheiros em filesystem (cooked files). Esta opção oferece uma flexibilidade extra caso necessitemos de mover os ficheiros físicos
Ficheiro "console"
Este ficheiro costuma ser de alguma forma ignorado por muitos clientes. É um ficheiro onde algumas mensagens são escritas. Normalmente não é muito necessário verificar estas mensagens. O caminho completo é definido por um parâmetro do $ONCONFIG (CONSOLE)
Restore point dir
É uma localização em filesystem (diretório) onde o Informix escreve alguma informação durante os upgrades. É definido por um parâmetro do $ONCONFIG (RESTORE_POINT_DIR)
LTAPEDEV/TAPEDEV
São as localizações para o backup dos logical logs e backup de instâncias, definidos pelos parâmetros de $ONCONFIG com o mesmo nome. Podem ser definidos com um valor especial ("/dev/null") se quisermos descartar os objetos. Note-se que o LTAPEDEV requer um restart da instância para mudar de/para "/dev/null". Normalmente apontam para um diretório no file system (ou em versões muito antigas do Informix apontarão para ficheiros). Se usarmos um storage manager o seu valor não é muito importante (exceto se o LTAEPDEV estiver para "/dev/null" - isto não é compatível com a utilização de um storage manager), visto que na realidade os objetos não serão guardados nesta localização, mas antes enviados para o storage manager.
Log de atividade do onbar
Log de atividade de backup usando o onbar. Definido por um parâmetro do $ONCONFIG (BAR_ACT_LOG)
Log de debug do onbar
Localização onde é escrito o debug do onbar. Apenas é usado se ativarmos o debug. O seu valor é definido por um parâmetro do $ONCONFIG (BAR_DEBUG_LOG)
Ficheiro IXBAR
Um ficheiro muito importante que contém o catálogo do onbar. É definido pelo parâmetro BAR_IXBAR_PATH do $ONCONFIG. Por omissão é $INFORMIXDIR/etc/ixbar.N onde "N" é o valor do parâmetro SERVERNUM (único para cada instância)
Caminho da biblioteca BAR BSA
O caminho completo para a biblioteca XBSA que estamos a usar, caso estejamos a integrar com um storage manager. A localização será dependente da instalação do cliente Informix do storage manager. O valor é definido pelo parâmetro BAR_BSA_LIBPATH do $ONCONFIG
Database Library Path
A localização onde permitimos que o motor carregue bibliotecas dinâmicas para fins de extensibilidade. O valor é definido pelo parâmetro DB_LIBRARY_PATH do $ONCONFIG
Data Replication lost and found
Nome base onde os ambientes HDR podem guardar transações committed no servidor primário que não foram transmitidas com sucesso para o servidor secundário. Definido pelo parâmetro DRLOSTFOUND do $ONCONFIG
Diretório de dumps
Directório onde os dumps de memória partilhada e ficheiros de diagnóstico serão criados. Tem de ser uma localização com espaço suficiente para alguns dumps de memória (assumindo que a instância está configurada para os gerar em caso de falhas). A localização é definida pelo parâmetro "DUMPDIR" do $ONCONFIG
Alarmprogram
O script ou programa que é executado pelo motor quando certos eventos acontecem. A localização é definida pelo parâmetro ALARMPROGRAM do $ONCONFIG
System alarm program
Semelhante ao alarmprogram mas para ser chamado em casos de falhas graves (quedas do motor ou assert fails). Definido pelo parâmetro SYSALARMPROGRAM do $ONCONFIG
Log dos processadores virtuais para Java
Ficheiro que recebe os "traces" e "dumps" de "stack" do JVPs. Definido pelo parâmetro JVPLOGFILE do $ONCONFIG
ADTCFG
Ficheiro de configuração do audit. Existe no diretório $INFORMIXDIR/aaodir e depois de efetuadas alterações será criado o ficheiro adtcfg.N onde N é o valor do parâmetro $SERVERNUM

Aspetos a considerar

O INFORMIXDIX

A primeira coisa a considerar é o valor de $INFORMIXDIR. Muitas pessoas simplesmente usam /opt/informix ou /usr/informix e instalam aí o produto. Isto não é a melhor opção pois durante os upgrades devemos ter disponíveis ambas as versões (antiga e nova). Em alguns casos resolvem isto instalado o produto num diretório que contém a versão (vamos assumir o "meu" standard) como /usr/informix/srvr1210fc7w1 e depois criam um link simbólico do tipo /usr/informix/server que aponta para a instalação que pretendem usar. Isto pode funcionar quando existe apenas uma instância no servidor, mas torna-se complicado quando há várias instalações e se pretende a opção de fazer upgrades em alturas diferentes.

A existência de um cluster levanta ainda mais um problema. Deveremos instalar o produto em ambos os nós ou apenas numa localização controlada pelo cluster e que é movida entre os nós? Há quem defenda a ideia de uma única instalação (INFORMIXDIR) que é movida para o nó que se quer "ativo". Mas novamente, se temos várias instâncias e consideramos dividir a carga entre os nós (apenas tendo as instâncias todas num só nó se o outro estiver indisponível), uma só instalação não responde aos requisitos. Ter um só $INFORMIXDIR para cada instância que é movido dentro do cluster simplifica outros aspetos. Se temos um INFORMIXDIR no nó A, e outro INFORMIXDIR no nó B, teremos dois ficheiros $ONCONFIG, ADTCFG e eventualmente outros cujo caminho não pode ser mudado (só o nome).

Outro aspeto relacionado com isto, é se configurarmos a separação de funções (role separation), que é uma excelente funcionalidade do Informix (sem custos adicionais) que permite que diferentes grupos de pessoas tenham acesso a diferentes funções numa instância Informix, então um só INFORMIXDIR para várias instâncias não permite fazer também a segregação por instância. Embora na realidade a maioria dos clientes não tenha pessoas suficientes para a separação de uma única instância...

Ficheiros de log

Os ficheiros de log, como o online.log, o de actividade do onbar, o de debug do onbar etc. por vezes têm valores por omissão dentro do $INFORMIXDIR, e mesmo quando assim não é, muitas vezes encontro clientes que os colocam lá. O problema de fazer isto é simples. Quando fazemos um ugrade o histórico dos ficheiros perde-se, pois parte fica no $INFORMIXDIR antigo e outra parte no novo (ou obriga a cópia para que tal não aconteça)

Outro problema óbvio com os logs deriva de ambientes de cluster onde as instâncias "saltitam" entre o nó A e o nó B. Se os logs não estiverem a apontar uma uma localização comum nos dois nós, acabamos com partes dos ficheiros no nó A e outra parte no nó B.

Por outro lado, se os logs estiverem a apontar para uma localização comum perdemos o registo de onde estava a instância em cada momento (o que pode ser conveniente para despiste de problemas - mais sobre isto num futuro artigo)

Os chunks

Aqui a decisão é se usamos links simbólicos ou não. Isto era muito mais importante antigamente porque por vezes alguma alteração nos raw devices implicava um caminho diferente e não era possível trocar o nome dos chunks pelo qual o motor os conhece. Em ambientes modernos e versões recentes do Informix, podemos criar os raw devices com os nomes que quisermos (se necessitarmos de reconstruir ou mudar opções podemos re-utilizar os nomes), e também podemos mudar os caminhos como o Informix os conhece através de um falso backup/restore externo.

Os scripts

Normalmente as instâncias requerem um conjunto de scripts mantidos pelos DBAs. Mais uma vez, vezes demais eu vejo estes scripts dentro do $INFORMIXDIR ou $INFORMIXDIR/bin. Como mencionado atrás isto não é uma boa prática, pois durante os upgrades torna-se uma confusão, e o mesmo se passa se necessitarmos de várias instâncias no mesmo servidor e pensarmos em ter vários $INFORMIXDIR (bastando para isso que estejam em versões diferentes)

O difícil pode ser que alguns scripts podem ter se ser adaptados para cada instância. E novamente a existência de um cluster pode trazer problemas. Neste caso poderemos ter de manter tantas cópias quantos nós existam no mesmo. Se porventura o cluster permitir algum tipo de sistema de ficheiros partilhado (GPFS ou GFS/GFS2 por exemplo), poderá haver solução para isso.
Os casos em que um só script tem de estar adaptado a várias instâncias poderemos usar uma estrutura "case/esac" dentro do script, cujo condicionamento terá por base o valor de $INFORMIXSERVER. Podemos usar isto por exemplo para ter um "alarmprogram" comum, que pode ter por exemplo diferentes tipos de configuração de backups.

Recomendações

INFORMIXDIR

Normalmente instalo o produto numa localização que indique claramente a versão (/usr/informix/srvr1210fc7w1), mas depois utilizo um script (ixvirtdir) para criar um $INFORMIXDIR "especial" para cada instância. O script recebe alguns parâmetros como o $INFORMIXDIR existente (da instalação) e o novo (que normalmente defino com um sufixo igual ao INFORMIXSERVER). Opcionalmente posso dar os grupos de sistema operativo a que correspondem os DBSA, AAO e DBSSOs para a separação de funções.
O INFORMIXDIR "especial" será um novo diretório onde serão criados links simbólicos para os sub-diretórios existentes dentro de $INFORMIXDIR, com algumas exceções. Vejamos um exemplo:

castelo@primary:informix-> echo $INFORMIXSERVER $INFORMIXDIR
castelo /opt/informix/srvr1210fc7w1_castelo
castelo@primary:informix-> pwd
/opt/informix/srvr1210fc7w1_castelo
castelo@primary:informix-> ls -l
total 84
drwxrwx--- 2 informix ixaao    4096 Aug 18 02:46 aaodir
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 bin -> /opt/informix/srvr1210fc7w1/bin
drwxrwx--- 2 informix ixdbsso  4096 Aug  1 13:44 dbssodir
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 demo -> /opt/informix/srvr1210fc7w1/demo
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 doc -> /opt/informix/srvr1210fc7w1/doc
drwxrwxr-x 4 informix ixdbsa   4096 Aug 23 11:10 etc
lrwxrwxrwx 1 informix informix   34 Nov 13 03:21 extend -> /opt/informix/srvr1210fc7w1/extend
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 gls -> /opt/informix/srvr1210fc7w1/gls
lrwxrwxrwx 1 informix informix   33 Nov 13 03:21 gskit -> /opt/informix/srvr1210fc7w1/gskit
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 help -> /opt/informix/srvr1210fc7w1/help
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 incl -> /opt/informix/srvr1210fc7w1/incl
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 isa -> /opt/informix/srvr1210fc7w1/isa
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 lib -> /opt/informix/srvr1210fc7w1/lib
lrwxrwxrwx 1 informix informix   35 Nov 13 03:21 license -> /opt/informix/srvr1210fc7w1/license
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 msg -> /opt/informix/srvr1210fc7w1/msg
lrwxrwxrwx 1 informix informix   38 Nov 13 03:21 properties -> /opt/informix/srvr1210fc7w1/properties
lrwxrwxrwx 1 informix informix   35 Nov 13 03:21 release -> /opt/informix/srvr1210fc7w1/release
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 SDK -> /opt/informix/srvr1210fc7w1/SDK
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 snmp -> /opt/informix/srvr1210fc7w1/snmp
drwxrwx--- 3 informix ixdbsa   4096 Aug  1 13:44 ssl
drwxrwx--- 2 informix informix 4096 Aug 23 11:10 tmp

Portanto, o INFORMIXDIR é /opt/informix/srvr1210fc7w1_castelo. "castelo" é o INFORMIXSERVER que atúa como sufixo para se identificar facilmente a que instância pertence. A maioria dos sub-diretórios dentro do $INFORMIXDIR são apenas links simbólicos para a instalação base do produto. As exceções são "aaodir", "dbssodir", "etc", "ssl" e "tmp". Estes são criados como sub-diretórios por várias razões. Num ambiente cluster o INFORMIXDIR "virtual" pode ser um recurso de cluster e a instalação base seria ou um recurso de cluster (no caso se haver apenas uma instância, ou se a movimentação for feita em bloco), ou uma instalação local em cada nó. Note-se que ao criar aquela lista específica de sub-diretórios como sub-diretórios reais, estou a isolar tudo o que pode variar de uma instância para outra. Note-se também que tipicamente estes diretórios não deverão requerer muito espaço, com a possível exceção do "tmp" se estiver definido como DUMPDIR por exemplo.
Com este método podemos alcançar o máximo de flexibilidade e isolamento das instâncias para as seguintes situações:

Várias instâncias num só servidor
Ambiente de cluster, mesmo com várias instâncias que não sejam necessariamente movidas em bloco para outro(s) nós
Completa separação de papéis em cada instância, permitindo diferentes grupos para diferentes instâncias

$HOME do utilizador Informix

A $HOME do utilizador informix (vamos assumir /home/informix) deverá conter duas diretorias:
"bin" e "etc". Na "bin", coloco todos os scripts que utilizo para gestão das instâncias, incluindo o alarmprogram.sh. Na "etc" coloco todos os ficheiros ou scripts de configuração como:

sqlhosts (ficheiro único por máquina) facilita as configurações para queries distribuídas etc.
Ficheiro de configuração do meu script que permite posicionar o ambiente de cada instância (setinfx)
Ficheiro de configuração do alarmprogram.sh onde cada secção específica para cada instância é permitido por uma estrutura case/esac

Esta configuração não resolve os problemas de cluster. Num ambiente de cluster, assmindo que todos os nós podem ter alguma(s) instãncia(s) a correr ao mesmo tempo a estrutura da $HOME do informix tem de ser replicada pelos nós. No entanto se mover as instâncias em bloco, o diretório pode ser um recurso de cluster (ou pelo menos as duas referidas sub-diretorias). Em qualquer caso o "bin" tem de ser colocado na variável de ambiente $PATH.
Deve ser evitada a duplicação dos ficheiros de configuração (um por cada nó do cluster), nomeadamente do $INFORMIXSQLHOSTS, para que baste alterar num só nó. Uma hipótese para isto seria criar links simbólicos para um ficheiro num recurso de cluster

Log files and others

Coisas como o online.log, ficheiros de atividade e debug do onbar, ixbar.* etc. devem ser colocados num recurso de cluster que seja movido com a instância. Num ambiente não cluster estes ficheiros podem ser colocados por exemplo num sub-diretório da $HOME do informix como /home/informix/logs e /home/informix/conf
Mesmo que os ficheiros sejam criados num recurso de cluster associado à instâncias, prefiro criá-los com um sufixo como $INFORMIXSERVER (ex: online_$INFORMIXSERVER.log, ixbar.$INFORMIXSERVER etc.
É importante sublinhar a importância de ter apenas um IXBAR no cluster. Caso contrário iremos acabar com o catálogo espalhado pelo cluster o que tornará o processo de restore muito difícil ou impossível.

Chunks e links

Para os chunks ainda continuo a preferir usar links simbólicos. Estes podem apontar para cooked files ou RAW. Tantos os links como os ficheiros (RAW ou cooked) devem ser configurados como um recurso de cluster.

Diretórios de DUMP

Existem alguns diretórios que só são usados esporadicamente mas que são muito importantes. Um é usado na configuração do parâmetro DUMPDIR, onde os ficheiros de assert fails são escritos. De alguma forma semelhantes são os parâmetros RESTORE_POINT_DIR, DRLOSTFOUND e PLOG_OVERFLOW_PATH.
Estes são importantes em certas ocasiões ou actividades, mas normalmente após resolvido o problema os ficheiros podem ser removidos. Portanto, é importante que as suas localizações tenham espaço suficiente e sejam diretórios existentes, mas não é assim tão relevante se são específicos de uma instância ou uma só localização em cluster.

ixtempuse news / novidades sobre o ixtempuse

2016-10-11T21:30:00.000+01:00

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

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

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

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

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

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

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

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

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

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

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

Cloud replay and more... / Apresentação da cloud e mais...

2016-10-01T12:22:00.000+01:00

Review the Informix on cloud presentation, announcement, tips and something more (original version here: http://informix-technology.blogspot.com/2016/09/cloud-replay-and-more-apresentacao-da.html)

English version
Last Monday we had the webcast about the new Informix on Cloud offering. For those who couldn't attend the live conference, the webcast replay is available in the following address:
http://event.on24.com/wcc/r/1180944/97874EAFB7BAA6C10771A1D273B6BCEA

The official announcement can be found here (EMEA):
http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/9/877/ENUSZP16-0499/index.html&lang=en&request_locale=en

The slides for from the presentation were uploaded to slideshare.net:
http://bit.ly/2d6wqq7

The actual service can be accessed here:
https://console.ng.bluemix.net/catalog/services/informix-on-cloud/

The main characteristics of this offering are:

Users will have full (root) access and will be responsible for managing a Linux server (CentOS)
Informix advanced Enterprise Edition will be installed and Informix Warehouse Accelerator will be included (not configured)
There will be 4 sizes of server with different resources (CPU, Memory, DISK, Network)
The server will be available through public Interner access. It can be configured by the users to participate in a VPN for example
No managing, monitoring or backing up services are currently offered. This can change in the future, but currently the customer has total freedom to implement whatever best fits their requirements
It works as if a server was rented in the cloud and the customer used their Informix licenses but of course that's not necessary as customers are charged on a monthly base that includes everything, including product support

The lack of backup services is relative issue. IBM and other vendors have several methods for storage use in the cloud. Some solutions could be considered.
Actually something that I personally find interesting is the possibility to run backups to the cloud. Currently Informix already supports it for Amazon S3. But the implementation seems a bit too simplistic. Something I've been trying as an exercise seems more interesting and with a bit more potential: Our backup tool, onbar, interacts with the Storage managers using a standard and open protocol called XBSA. It's possible to create a XBSA library that sends the objects to the cloud. Just a few hours ago I managed to make my first restore from a previous backup sent to the cloud. It took me less than a week of free time to create this. It currently has less than 1000 lines of codes written by me. And yes, it's incomplete, doesn't have proper error handling or debugging, doesn't manage metadata or an object catalog etc. But it clearly shows it could be a path to cloud storage use for database backups. Additionally some cloud services (like IBM's Bluemix Object Storage) use a standard called SWIFT which makes it relatively easy to support several cloud providers if the library can be configured externally. Hopefully in the future I'll be able to write an article dedicated to this proof of concept.

Versão Portuguesa
Na passada segunda-feira tivemos o webcast sobre a nova oferta de Informix na nuvem. Para quem não pôde assistir em direto, a gravação da conferência está disponível no seguinte endereço:
http://event.on24.com/wcc/r/1180944/97874EAFB7BAA6C10771A1D273B6BCEA

O anúncio oficial pode ser encontrado em (EMEA):
http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/9/877/ENUSZP16-0499/index.html&lang=en&request_locale=en

Os slides da apresentação foram carregados no slideshare.net:
http://bit.ly/2d6wqq7

O serviço propriamente dito pode ser encontrado aqui:
https://console.ng.bluemix.net/catalog/services/informix-on-cloud/

As características principais do serviço são:

Os utilizadores terão acesso total (root), e serão responsáveis pela gestão de um servidor Linux (CentOS)
A edição Advanced Enterprise do Informix estará instalada e o Informix Warehouse Accelerator estará disponível para configuração
Existem 4 tamanhos para os servidores com diferentes recursos (CPU, memória, disco e rede)
O servidor estará acessível pela Internet pública. Poderá ser configurado pelos utilizadores para fazer parte de uma VPN
Não são oferecidos serviços de gestão, monitorização ou backup. Estes aspectos poderão vir a ser alterados no futuro, mas neste momento os clientes têm total liberdade para implementar o que quer que seja que complete o que é oferecido agora, conforme as suas necessidades
Funciona como se o cliente alugasse um servidor na nuvem e usasse as suas prórpias licenças, embora isso não seja obviamente necessário visto que o serviço é facturado numa base mensal que inclúi a utilização e o suporte do produto

A falta de um serviço de backup é um problema relativo. Tanto a IBM como outros fornecedores têm disponíveis vários métodos de utilização de armazenamento na nuvem. Poderão ser consideradas algumas soluções.
Na verdade, algo que eu pessoalmente acho interessante é a possibilidade de executar backups para a nuvem. O Informix já disponibiliza essa funcionalidade para o serviço S3 da Amazon. Mas a implementação parece um pouco simplista ou limitada (usa o ontape). Algo que tenho estado a testar como exercício parece-me mais interessante e com mais potencial. A nossa ferramenta de backup, o onbar, interage com os storage managers utilizando um protocolo aberto e standards chamado XBSA. É possível criar uma biblioteca XBSA que envie os objetos para a nuvem. Há apenas algumas horas atrás consegui fazer o primeiro restore a partir de um backup para a nuvem. Levei menos de uma semana de ocupação de tempos livres a criar isto. Neste momento tem menos de 1000 linhas de código escrito por mim. E sim, não tem gestão de erros adequada, ou debugging, não gere metadata nem possuí um catálogo de objetos etc. Mas serve para mostrar claramente que este poderia ser um caminho para integração de backups com a nuvem. Por acréscimo, alguns dos serviços de armazenamento na nuvem (como o Object Storage no IBM Bluemix) utilizam um standard chamado SWIFT . o que tornaria mais fácil suportar vários serviços desde que a biblioteca pudesse ser configurada externamente. Espero no futuro conseguir fazer um artigo dedicado apenas a este tema

Sysadmin during upgrades / Sysadmin durante upgrades

2016-09-30T07:00:00.000+01:00

Curious situation related to sysadmin during an upgrade (original version here: http://informix-technology.blogspot.com/2016/09/sysadmin-during-upgrades-sysadmin.html)

English version
Recently at a customer we were testing an upgrade from 11.50.xC7 to 12.10.xC7W1 and it apparently hanged. That's not what you like to see during an upgrade, even in a test environment.
We waited a few minutes and tried to understand what was happening. There was a thread called "convert" that apparently was idle. The thread stack trace apparently didn't change.
The functions showing up in the stack suggested it was trying to connect to a remote server following up what looks to be a call to UPDATE STATISTICS. That was a bit of a surprise.... looking at the online.log it was "hanged" during the "SCHAPI" phase. This is related to sysadmin.
Considering the upgrade didn't look good and it was a test system we decided to kill the engine and use onrestorept to revert back to version 11.50.
Then we decided to run an UPDATE STATISTICS FOR PROCEDURE on sysadmin database and voilá.... hanged again.
So, an UPDATE STATISTICS FOR PROCEDURE on sysadmin got hanged, and apparently that same thing happened during the upgrade. Further investigation led to a simple conclusion. We had created procedures in sysadmin to implement some monitoring tasks. And some of them tried to do remote operations on an engine where we centralize the monitoring data. Just before the upgrade a change was made to the instance $INFORMIXSQLHOSTS so that we "isolated" it from the outside world. This was done by adding some value to the service ports. The consequence of this was that during the upgrade, when it tried to run the UPDATE STATISTICS FOR PROCEDURE it tried to access a non-reachable remote engine. As it was not possible, it hanged some time for each remote instruction. Later tests on 12.10 showed the time it waits for each connection attempt is by default 60s and can be defined by changing the relatively new ONCONFIG parameter INFORMIXCONTIME

This can be easily reproduced. On a version 11.50 engine we create a simple (dumb) procedure:

bica@primary:informix-> onstat -



IBM Informix Dynamic Server Version 11.50.FC7     -- On-Line -- Up 00:30:33 -- 269068 Kbytes

bica@primary:informix-> cat test_remote_proc_stats.sql





CREATE PROCEDURE test_updstats_remote()



DEFINE i INTEGER;



SELECT 1 INTO i FROM stores@test:systables WHERE tabid = 1;



SELECT 2 INTO i FROM somedb@test:systables WHERE tabid = 1;



END PROCEDURE;

bica@primary:informix->





bica@primary:informix-> dbaccess sysadmin test_remote_proc_stats.sql



Database selected.



Routine created.



Database closed.

bica@primary:informix->

Database server "test" exists in the $INFORMIXSQLHOSTS, but points to a wrong port. Let's try an upgrade to 12.10.FC7 and see what happens.

From the online.log we get:



01:30:52  IBM Informix Dynamic Server Started.

01:30:52  Requested shared memory segment size rounded from 4308KB to 4796KB



Wed Aug 31 01:30:54 2016



01:30:54  Requested shared memory segment size rounded from 221001KB to 221004KB

01:30:54  Successfully added a bufferpool of page size 2K.



01:30:54  Event alarms enabled.  ALARMPROG = '/usr/informix/srvr1210fc7w1/etc/alarmprogram.sh'

01:30:54  Booting Language  from module <>

01:30:54  Loading Module 

01:30:54  Booting Language  from module <>

01:30:54  Loading Module 

01:30:59  DR: DRAUTO is 0 (Off)

01:30:59  DR: ENCRYPT_HDR is 0 (HDR encryption Disabled)

01:30:59  Event notification facility epoll enabled.

01:31:00  Trusted host cache successfully built:/etc/hosts.equiv.

01:31:00  CCFLAGS2 value set to 0x200

01:31:00  SQL_FEAT_CTRL value set to 0x8008

01:31:00  SQL_DEF_CTRL value set to 0x4b0

01:31:00  IBM Informix Dynamic Server Version 12.10.FC7W1 Software Serial Number AAA#B000000

01:31:00  Conversion from version 11.50.xC6 Started



[...]



01:31:05  processing sysmaster

01:31:05  *** entity_ver=31  targetVersion=36  indexVersion= 0 ***

01:31:05  *** FromVersion=10  ToVersion=26 entity_ver=31 targetVersion=36 indexVersion=0 ***

01:31:05  *** FromVersion=26  ToVersion=28 entity_ver=31 targetVersion=36 indexVersion=1 ***

01:31:05  *** FromVersion=28  ToVersion=29 entity_ver=31 targetVersion=36 indexVersion=2 ***

01:31:05  *** FromVersion=29  ToVersion=30 entity_ver=31 targetVersion=36 indexVersion=3 ***

01:31:05  *** FromVersion=30  ToVersion=31 entity_ver=31 targetVersion=36 indexVersion=4 ***

01:31:05  *** FromVersion=31  ToVersion=32 entity_ver=31 targetVersion=36 indexVersion=5 ***

01:31:05  *** SQL 1 11.70.xC1 ***

01:31:05  Converting database sysmaster ...

01:31:06  The database sysmaster has been converted successfully.

01:31:06  *** FromVersion=32  ToVersion=33 entity_ver=32 targetVersion=36 indexVersion=6 ***

01:31:06  *** SQL 1 11.70.xC3 ***

01:31:06  Converting database sysmaster ...

01:31:06  The database sysmaster has been converted successfully.

01:31:06  *** FromVersion=33  ToVersion=34 entity_ver=33 targetVersion=36 indexVersion=7 ***

01:31:06  *** SQL 1 12.10.xC1 ***

01:31:06  Converting database sysmaster ...

01:31:06  The database sysmaster has been converted successfully.

01:31:06  *** FromVersion=34  ToVersion=35 entity_ver=34 targetVersion=36 indexVersion=8 ***

01:31:06  *** SQL 1 12.10.xC4 ***

01:31:06  Converting database sysmaster ...

01:31:06  The database sysmaster has been converted successfully.

01:31:06  *** FromVersion=35  ToVersion=36 entity_ver=35 targetVersion=36 indexVersion=9 ***

01:31:06  *** SQL 1 12.10.xC4 ***

01:31:06  processing sysutils



[...]



01:31:17  Conv/rev: calling conversion to 12.10.xC1 ...

01:31:19  Conv/rev: blade conversion to 12.10.xC1 completed

01:31:19  *** FromVersion=6  ToVersion=7 entity_ver=6 targetVersion=7 indexVersion=6 ***

01:31:19  *** BLADE 1 12.10.xC4 ***

01:31:19  Conv/rev: calling conversion to 12.10.xC4 ...

01:31:21  Conv/rev: blade conversion to 12.10.xC4 completed

01:31:21  Conv/rev: Finished conversion for component BLADE

01:31:21  Conv/rev: Started conversion for component SCHAPI

01:31:21  *** numVersions=7 targetVersion=7 ***

01:31:21  *** entity_ver=3  targetVersion=7  indexVersion= 0 ***

01:31:21  *** FromVersion=0  ToVersion=1 entity_ver=3 targetVersion=7 indexVersion=0 ***

01:31:21  *** FromVersion=1  ToVersion=2 entity_ver=3 targetVersion=7 indexVersion=1 ***

01:31:21  *** FromVersion=2  ToVersion=3 entity_ver=3 targetVersion=7 indexVersion=2 ***

01:31:21  *** FromVersion=3  ToVersion=4 entity_ver=3 targetVersion=7 indexVersion=3 ***

01:31:21  *** SCHAPI 1 11.70.xC1 ***

01:31:21  calling schapi_cvr1170_convert

01:31:21  *** FromVersion=4  ToVersion=5 entity_ver=4 targetVersion=7 indexVersion=4 ***

01:31:21  *** SCHAPI 1 11.70.xC3 ***

and it hangs...
Looking into the threads and thread stack:



IBM Informix Dynamic Server Version 12.10.FC7W1 -- Single-User -- Up 00:00:54 -- 266648 Kbytes



Threads:

tid     tcb              rstcb            prty status                vp-class       name

2        4579d9e8         0                1    IO Idle                 3lio*        lio vp 0

3        458fd368         0                1    IO Idle                 4pio*        pio vp 0

4        4591e368         0                1    IO Idle                 5aio*        aio vp 0

5        4593f368         1d43600          1    IO Idle                 6msc*        msc vp 0

6        45970368         0                1    IO Idle                 7fifo*       fifo vp 0

7        45991608         44c1e028         3    sleeping secs: 1        1cpu         main_loop()

8        459ed4c0         0                1    running                 8soc*        soctcppoll

9        459edc98         0                2    sleeping forever        1cpu*        soctcplst

10       45a3cc88         44c1e8f0         1    sleeping secs: 1        1cpu         flush_sub(0)

11       45a59028         44c1f1b8         1    sleeping secs: 1        1cpu         flush_sub(1)

12       45a59368         44c1fa80         1    sleeping secs: 1        1cpu         flush_sub(2)

13       45a596a8         44c20348         1    sleeping secs: 1        1cpu         flush_sub(3)

14       45a599e8         44c20c10         1    sleeping secs: 1        1cpu         flush_sub(4)

15       45a59d28         44c214d8         1    sleeping secs: 1        1cpu         flush_sub(5)

16       45ab70e0         44c21da0         1    sleeping secs: 1        1cpu         flush_sub(6)

17       45ab7420         44c22668         1    sleeping secs: 1        1cpu         flush_sub(7)

18       45ab7760         0                3    IO Idle                 1cpu*        kaio

19       45c0c2c8         44c22f30         3    sleeping secs: 1        1cpu         convert

20       45c0c9f8         44c237f8         2    sleeping secs: 1        1cpu         aslogflush

21       45ccc958         44c240c0         1    sleeping secs: 8        1cpu         btscanner_0

22       45ceba00         44c24988         3    cond wait  ReadAhead    1cpu         readahead_0

23       45d0eb50         44c25250         3    sleeping secs: 1        1cpu         auto_tune

27       45d8aa80         44c25b18         1    sleeping secs: 0        1cpu         sbspclean

28       45d30aa8         44c26ca8         1    sleeping secs: 1        1cpu         defragclean

30       45d738f0         44c27570         3    sleeping secs: 1        1cpu*        onmode_mon

31       45d89028         44c27e38         3    sleeping secs: 1        1cpu         periodic

32       45d89608         44c28700         3    sleeping forever        1cpu         memory

33       45d89be8         44c28fc8         3    sleeping secs: 15       1cpu         session_mgr

35       45e08768         44c263e0         1    cond wait  bp_cond      1cpu         bf_priosweep()



IBM Informix Dynamic Server Version 12.10.FC7W1 -- Single-User -- Up 00:01:03 -- 266648 Kbytes



Stack for thread: 19 convert

base: 0x0000000045c19000

len:   69632

pc: 0x00000000013eaa6f

tos: 0x0000000045c24d50

state: sleeping

vp: 1



0x00000000013eaa6f (oninit) yield_processor_svp

0x00000000013ed5d3 (oninit) mt_yield

0x0000000001501340 (oninit) net_wait_for_connect

0x0000000001506ade (oninit) connsocket

0x000000000155f3c0 (oninit) tlConnect

0x000000000155c56a (oninit) slSQIreq

0x0000000001555343 (oninit) pfConReq

0x000000000154c628 (oninit) cmReqSync

0x000000000154d7ef (oninit) cmConReq

0x00000000014ee62e (oninit) ASF_Call

0x000000000076fd94 (oninit) dd_newconnect

0x00000000007712d0 (oninit) dd_remconnect

0x0000000000765404 (oninit) remcatalog

0x0000000000734831 (oninit) readtab

0x000000000073a372 (oninit) ddgettable_hierarchy_trace

0x00000000006bd1d5 (oninit) aud_ddgettable_trace

0x0000000000601206 (oninit) gettab_trace

0x0000000000655f15 (oninit) tlgetddtab_trace

0x0000000000656530 (oninit) tlp2tnode

0x000000000065af3b (oninit) tbl2tab

0x000000000063785d (oninit) sel2cb

0x0000000000639498 (oninit) subq2cb

0x00000000006632c1 (oninit) sq2expr

0x0000000000663373 (oninit) subq2expr

0x000000000066cca4 (oninit) expr2expr

0x0000000000682764 (oninit) ip_exprparse

0x00000000006a28fe (oninit) cmp_stmt

0x00000000006a2c1d (oninit) pr_compile

0x00000000006bf021 (oninit) aud_pr_compile

0x00000000006a3987 (oninit) updprocstat

0x00000000005cfba6 (oninit) excommand

0x0000000000f7eed7 (oninit) admin_exec_cmd

0x0000000000f7f2d5 (oninit) run_sql_script

0x0000000000f7f418 (oninit) run_script_etc

0x0000000000f9b826 (oninit) run_script_conv

0x0000000000f9b936 (oninit) ph_convrev

0x0000000000f42233 (oninit) schapi_cvr1170XC3_convert

0x0000000000f3f906 (oninit) do_each_version_work

0x0000000000f402d3 (oninit) generic_fw_main

0x0000000000f40cf6 (oninit) convertSM

0x00000000013c3720 (oninit) th_init_initgls

0x000000000142a518 (oninit) startup

The stack trace is clear. And precisely 2 minutes later it continues:



01:31:21  *** SCHAPI 1 11.70.xC3 ***

01:33:22  *** FromVersion=5  ToVersion=6 entity_ver=5 targetVersion=7 indexVersion=5 ***

01:33:22  *** SCHAPI 1 12.10.xC1 ***

01:33:22  calling schapi_cvr1210_convert

01:33:22  *** FromVersion=6  ToVersion=7 entity_ver=6 targetVersion=7 indexVersion=6 ***

01:33:22  *** SCHAPI 1 12.10.xC4 ***

01:33:22  calling schapi_cvr1210XC4_convert

01:33:23  Dynamically allocated new virtual shared memory segment (size 8192KB)

01:33:23  Memory sizes:resident:4796 KB, virtual:270044 KB, no SHMTOTAL limit

01:33:23  Conv/rev: Finished conversion for component SCHAPI

And it completed the conversion. In the customer situation, a later test showed a "hang" period of around 45m. So, a big warning.... The conversion process will run an UPDATE STATISTICS FOR PROCEDURE on sysadmin database. If you have created some procedures that do remote/distributed operations than you must consider this "problem" during the upgrade. Here are your options:

Allow connections to that remote server(s)
Remove the procedures and recreate them
Use INFORMIXCONTIME parameter (12.10 only) to reduce the timeouts
Remove the remote INFORMIXSERVER from the INFORMIXSQLHOSTS during migration. This also makes the connections attempts very quickly (as it simply can't find where to connect)

Versão Portuguesa
Há algum tempo num cliente, estando a testar uma migração de uma versão 11.50.FC7 para 12.10.FC7W1 deparámo-nos com um aparente bloqueio. Não é o que gostamos de ver, ainda que seja num ambiente de testes.
Esperámos uns minutos e tentámos perceber o que se estava a passar. Havia uma thread chamada "convert" que aparentemente estava inativa. O seu stack trace não parecia mudar
As funções que apareciam no stack sugeriam que estava a tentar contactar um servidor remoto, seguindo o que parecia ser uma chamada a um UPDATE STATISTICS. Isto foi uma grande surpresa.... Olhando para o online.log estava parado na fase "SCHAPI". Isto está relacionado com a sysadmin.
Considerando que o upgrade não estava com bom aspeto e que se tratava de um ambiente de testes decidimos abortar e usámos o onrestorept para reverter para a versão 11.50 (umas das minhas funcionalidades favoritas).
Para efeitos de teste e investigação decidimos executar um UPDATE STATISTICS FOR PROCEDURE na base de dados sysadmin. E voilá, preso de novo.
Portanto um UPDATE STATISTICS FOR PROCEDURE na sysadmin bloqueava o sistema e isso teria acontecido durante o upgrade. Após mais investigação concluímos que tínhamos criado procedimentos nesta base de dados para implementar algumas tarefas de monitorização e que esses procedimentos executavam algumas operações remotas para enviar a informação de monitorização para um sistema central. E antes do upgrade tinha sido feito uma alteração "de rotina" que consistiu na alteração do $INFORMIXSQLHOSTS de forma a "isolar" este motor. Basicamente foi adicionado um valor a todas as portas dos listeners, o que faz com que os clientes (não alterados) não consigam chegar ao ambiente. A consequência disto é que quando efetuamos o UPDATE STATISTICS este motor tenta aceder ao(s) motores referenciados nas operações remotas o que também não será possível. E como tal temos um timeout por cada operação remota encontrada nos procedimentos. Testes posteriores na 12.10 mostraram que a espera por cada tentativa de conexão é o valor por omissão (60s) ou o que estiver definido no parâmetro de $ONCONFIG INFORMIXCONTIME introduzido recentemente.

Tudo isto pode ser reproduzido facilmente. Num motor com a versão 11.50 criamos um procedimento simples (inútil):

bica@primary:informix-> onstat -



IBM Informix Dynamic Server Version 11.50.FC7     -- On-Line -- Up 00:30:33 -- 269068 Kbytes

bica@primary:informix-> cat test_remote_proc_stats.sql





CREATE PROCEDURE test_updstats_remote()



DEFINE i INTEGER;



SELECT 1 INTO i FROM stores@test:systables WHERE tabid = 1;



SELECT 2 INTO i FROM somedb@test:systables WHERE tabid = 1;



END PROCEDURE;

bica@primary:informix->





bica@primary:informix-> dbaccess sysadmin test_remote_proc_stats.sql



Database selected.



Routine created.



Database closed.

bica@primary:informix->

O servidor de base de dados "test" existe no $INFORMIXSQLHOSTS, mas aponta para um serviço não existente. Tentemos um upgrade para a 12.10.FC7 e vejamos o que acontece:

No online.log temos:



01:30:52  IBM Informix Dynamic Server Started.

01:30:52  Requested shared memory segment size rounded from 4308KB to 4796KB



Wed Aug 31 01:30:54 2016



01:30:54  Requested shared memory segment size rounded from 221001KB to 221004KB

01:30:54  Successfully added a bufferpool of page size 2K.



01:30:54  Event alarms enabled.  ALARMPROG = '/usr/informix/srvr1210fc7w1/etc/alarmprogram.sh'

01:30:54  Booting Language  from module <>

01:30:54  Loading Module 

01:30:54  Booting Language  from module <>

01:30:54  Loading Module 

01:30:59  DR: DRAUTO is 0 (Off)

01:30:59  DR: ENCRYPT_HDR is 0 (HDR encryption Disabled)

01:30:59  Event notification facility epoll enabled.

01:31:00  Trusted host cache successfully built:/etc/hosts.equiv.

01:31:00  CCFLAGS2 value set to 0x200

01:31:00  SQL_FEAT_CTRL value set to 0x8008

01:31:00  SQL_DEF_CTRL value set to 0x4b0

01:31:00  IBM Informix Dynamic Server Version 12.10.FC7W1 Software Serial Number AAA#B000000

01:31:00  Conversion from version 11.50.xC6 Started



[...]



01:31:05  processing sysmaster

01:31:05  *** entity_ver=31  targetVersion=36  indexVersion= 0 ***

01:31:05  *** FromVersion=10  ToVersion=26 entity_ver=31 targetVersion=36 indexVersion=0 ***

01:31:05  *** FromVersion=26  ToVersion=28 entity_ver=31 targetVersion=36 indexVersion=1 ***

01:31:05  *** FromVersion=28  ToVersion=29 entity_ver=31 targetVersion=36 indexVersion=2 ***

01:31:05  *** FromVersion=29  ToVersion=30 entity_ver=31 targetVersion=36 indexVersion=3 ***

01:31:05  *** FromVersion=30  ToVersion=31 entity_ver=31 targetVersion=36 indexVersion=4 ***

01:31:05  *** FromVersion=31  ToVersion=32 entity_ver=31 targetVersion=36 indexVersion=5 ***

01:31:05  *** SQL 1 11.70.xC1 ***

01:31:05  Converting database sysmaster ...

01:31:06  The database sysmaster has been converted successfully.

01:31:06  *** FromVersion=32  ToVersion=33 entity_ver=32 targetVersion=36 indexVersion=6 ***

01:31:06  *** SQL 1 11.70.xC3 ***

01:31:06  Converting database sysmaster ...

01:31:06  The database sysmaster has been converted successfully.

01:31:06  *** FromVersion=33  ToVersion=34 entity_ver=33 targetVersion=36 indexVersion=7 ***

01:31:06  *** SQL 1 12.10.xC1 ***

01:31:06  Converting database sysmaster ...

01:31:06  The database sysmaster has been converted successfully.

01:31:06  *** FromVersion=34  ToVersion=35 entity_ver=34 targetVersion=36 indexVersion=8 ***

01:31:06  *** SQL 1 12.10.xC4 ***

01:31:06  Converting database sysmaster ...

01:31:06  The database sysmaster has been converted successfully.

01:31:06  *** FromVersion=35  ToVersion=36 entity_ver=35 targetVersion=36 indexVersion=9 ***

01:31:06  *** SQL 1 12.10.xC4 ***

01:31:06  processing sysutils



[...]



01:31:17  Conv/rev: calling conversion to 12.10.xC1 ...

01:31:19  Conv/rev: blade conversion to 12.10.xC1 completed

01:31:19  *** FromVersion=6  ToVersion=7 entity_ver=6 targetVersion=7 indexVersion=6 ***

01:31:19  *** BLADE 1 12.10.xC4 ***

01:31:19  Conv/rev: calling conversion to 12.10.xC4 ...

01:31:21  Conv/rev: blade conversion to 12.10.xC4 completed

01:31:21  Conv/rev: Finished conversion for component BLADE

01:31:21  Conv/rev: Started conversion for component SCHAPI

01:31:21  *** numVersions=7 targetVersion=7 ***

01:31:21  *** entity_ver=3  targetVersion=7  indexVersion= 0 ***

01:31:21  *** FromVersion=0  ToVersion=1 entity_ver=3 targetVersion=7 indexVersion=0 ***

01:31:21  *** FromVersion=1  ToVersion=2 entity_ver=3 targetVersion=7 indexVersion=1 ***

01:31:21  *** FromVersion=2  ToVersion=3 entity_ver=3 targetVersion=7 indexVersion=2 ***

01:31:21  *** FromVersion=3  ToVersion=4 entity_ver=3 targetVersion=7 indexVersion=3 ***

01:31:21  *** SCHAPI 1 11.70.xC1 ***

01:31:21  calling schapi_cvr1170_convert

01:31:21  *** FromVersion=4  ToVersion=5 entity_ver=4 targetVersion=7 indexVersion=4 ***

01:31:21  *** SCHAPI 1 11.70.xC3 ***

e bloqueia...
Vejamos as threads e o respetivo stack:



IBM Informix Dynamic Server Version 12.10.FC7W1 -- Single-User -- Up 00:00:54 -- 266648 Kbytes



Threads:

tid     tcb              rstcb            prty status                vp-class       name

2        4579d9e8         0                1    IO Idle                 3lio*        lio vp 0

3        458fd368         0                1    IO Idle                 4pio*        pio vp 0

4        4591e368         0                1    IO Idle                 5aio*        aio vp 0

5        4593f368         1d43600          1    IO Idle                 6msc*        msc vp 0

6        45970368         0                1    IO Idle                 7fifo*       fifo vp 0

7        45991608         44c1e028         3    sleeping secs: 1        1cpu         main_loop()

8        459ed4c0         0                1    running                 8soc*        soctcppoll

9        459edc98         0                2    sleeping forever        1cpu*        soctcplst

10       45a3cc88         44c1e8f0         1    sleeping secs: 1        1cpu         flush_sub(0)

11       45a59028         44c1f1b8         1    sleeping secs: 1        1cpu         flush_sub(1)

12       45a59368         44c1fa80         1    sleeping secs: 1        1cpu         flush_sub(2)

13       45a596a8         44c20348         1    sleeping secs: 1        1cpu         flush_sub(3)

14       45a599e8         44c20c10         1    sleeping secs: 1        1cpu         flush_sub(4)

15       45a59d28         44c214d8         1    sleeping secs: 1        1cpu         flush_sub(5)

16       45ab70e0         44c21da0         1    sleeping secs: 1        1cpu         flush_sub(6)

17       45ab7420         44c22668         1    sleeping secs: 1        1cpu         flush_sub(7)

18       45ab7760         0                3    IO Idle                 1cpu*        kaio

19       45c0c2c8         44c22f30         3    sleeping secs: 1        1cpu         convert

20       45c0c9f8         44c237f8         2    sleeping secs: 1        1cpu         aslogflush

21       45ccc958         44c240c0         1    sleeping secs: 8        1cpu         btscanner_0

22       45ceba00         44c24988         3    cond wait  ReadAhead    1cpu         readahead_0

23       45d0eb50         44c25250         3    sleeping secs: 1        1cpu         auto_tune

27       45d8aa80         44c25b18         1    sleeping secs: 0        1cpu         sbspclean

28       45d30aa8         44c26ca8         1    sleeping secs: 1        1cpu         defragclean

30       45d738f0         44c27570         3    sleeping secs: 1        1cpu*        onmode_mon

31       45d89028         44c27e38         3    sleeping secs: 1        1cpu         periodic

32       45d89608         44c28700         3    sleeping forever        1cpu         memory

33       45d89be8         44c28fc8         3    sleeping secs: 15       1cpu         session_mgr

35       45e08768         44c263e0         1    cond wait  bp_cond      1cpu         bf_priosweep()



IBM Informix Dynamic Server Version 12.10.FC7W1 -- Single-User -- Up 00:01:03 -- 266648 Kbytes



Stack for thread: 19 convert

base: 0x0000000045c19000

len:   69632

pc: 0x00000000013eaa6f

tos: 0x0000000045c24d50

state: sleeping

vp: 1



0x00000000013eaa6f (oninit) yield_processor_svp

0x00000000013ed5d3 (oninit) mt_yield

0x0000000001501340 (oninit) net_wait_for_connect

0x0000000001506ade (oninit) connsocket

0x000000000155f3c0 (oninit) tlConnect

0x000000000155c56a (oninit) slSQIreq

0x0000000001555343 (oninit) pfConReq

0x000000000154c628 (oninit) cmReqSync

0x000000000154d7ef (oninit) cmConReq

0x00000000014ee62e (oninit) ASF_Call

0x000000000076fd94 (oninit) dd_newconnect

0x00000000007712d0 (oninit) dd_remconnect

0x0000000000765404 (oninit) remcatalog

0x0000000000734831 (oninit) readtab

0x000000000073a372 (oninit) ddgettable_hierarchy_trace

0x00000000006bd1d5 (oninit) aud_ddgettable_trace

0x0000000000601206 (oninit) gettab_trace

0x0000000000655f15 (oninit) tlgetddtab_trace

0x0000000000656530 (oninit) tlp2tnode

0x000000000065af3b (oninit) tbl2tab

0x000000000063785d (oninit) sel2cb

0x0000000000639498 (oninit) subq2cb

0x00000000006632c1 (oninit) sq2expr

0x0000000000663373 (oninit) subq2expr

0x000000000066cca4 (oninit) expr2expr

0x0000000000682764 (oninit) ip_exprparse

0x00000000006a28fe (oninit) cmp_stmt

0x00000000006a2c1d (oninit) pr_compile

0x00000000006bf021 (oninit) aud_pr_compile

0x00000000006a3987 (oninit) updprocstat

0x00000000005cfba6 (oninit) excommand

0x0000000000f7eed7 (oninit) admin_exec_cmd

0x0000000000f7f2d5 (oninit) run_sql_script

0x0000000000f7f418 (oninit) run_script_etc

0x0000000000f9b826 (oninit) run_script_conv

0x0000000000f9b936 (oninit) ph_convrev

0x0000000000f42233 (oninit) schapi_cvr1170XC3_convert

0x0000000000f3f906 (oninit) do_each_version_work

0x0000000000f402d3 (oninit) generic_fw_main

0x0000000000f40cf6 (oninit) convertSM

0x00000000013c3720 (oninit) th_init_initgls

0x000000000142a518 (oninit) startup

O stack é claro. E precisamente 2 minutos depois a conversão continua (o procedimento tinha duas instruções remotas):



01:31:21  *** SCHAPI 1 11.70.xC3 ***

01:33:22  *** FromVersion=5  ToVersion=6 entity_ver=5 targetVersion=7 indexVersion=5 ***

01:33:22  *** SCHAPI 1 12.10.xC1 ***

01:33:22  calling schapi_cvr1210_convert

01:33:22  *** FromVersion=6  ToVersion=7 entity_ver=6 targetVersion=7 indexVersion=6 ***

01:33:22  *** SCHAPI 1 12.10.xC4 ***

01:33:22  calling schapi_cvr1210XC4_convert

01:33:23  Dynamically allocated new virtual shared memory segment (size 8192KB)

01:33:23  Memory sizes:resident:4796 KB, virtual:270044 KB, no SHMTOTAL limit

01:33:23  Conv/rev: Finished conversion for component SCHAPI

E termina a conversão. Na situação concreta do cliente, um novo teste com a mesma instância apresentou um "bloqueio" durante cerca de 45m (correspondente a sensivelmente o mesmo número de instruções remotas nos procedimentos da sysadmin). Portanto um grande alerta...: O processo de conversão irá executar um UPDATE STATISTICS FOR PROCEDURE na base de dados sysadmin (isto não está documentado, mas é natural tendo em conta o processo de conversão da mesma). Se porventura criou procedimentos que acedem a instâncias remotas, então deverá ter isto em conta As opções para lidar com isto serão::

Permitir as ligações ao(s) servidor remoto
Remover os procedimentos e recriá-los depois da migração
Usar o parâmetro INFORMIXCONTIME (a partir da 12.10) para reduzir os tempos de espera
Remover o INFORMIXSERVER remoto do $INFORMIXSQLHOSTS durante a conversão. Isto também permite acelerar as tentativas de conexão pois ao não encontrar a referência no ficheiro o motor não sabe onde se ligar, e portanto não se aplicam os timeouts

Temporary space usage / Uso de espaço temporário

2016-09-21T23:34:00.000+01:00

How do you find which sessions are consuming temporary space? (original version here: http://informix-technology.blogspot.com/2016/09/temporary-space-usage-uso-de-espaco.html)

English version

Introduction

Informix has a few rocks in it's shoes, or skeletons in the closet as we prefer. In my opinion the ones I consider as such are lack of specific functionality, undesirable behavior or inability to provide information to the DBA. I believe I've opened RFEs (request for enhancements) for most if not all of them, and my favorites are probably:

Inability to easily see who is consuming temporary space (RFE 77879 and RFE 43877)
Inability to generate a query plan for a running query (RFE 33800)
Default behavior on non-ANSI databases regarding privileges on new objects (or lack of NODEFDAC $ONCONFIG equivalent - RFE 34407 and RFE 60849)

I've opened two RFEs, for a couple of situations because the first was refused or erroneously considered delivered (in my opinion of course). There are a few others like the string truncation in non-ANSI databases without warning, inability to use PAM with OlEDB clients - password only), missing SID in the audit logs etc...

From these, the first doesn't seem to have any progress and I believe it's a serious limitation for the DBA's daily work. And even if R&D decides to implement it, it would probably not be back ported to currently existing versions, which are to be supported for several years. So it means customers would not benefit from it, even if it was implemented today. And considering IBM closed my first attempt on the basis that we were working on the session limit configurations, I doubt this will be considered a priority. As a side note, the possibility to limit the use of temporary space is a very welcomed feature. But the fact that you can configure something, doesn't mean you won't need to monitor it. I believe this is common sense.

Script solution and usage

Well, considering all this, and after learning a few more things about the engine I noticed it would be possible to create something that can help customers with existing versions regarding the first two issues above (temporary space usage and running query plan). At this moment all I have in a "sharable" state is a script to report on temporary space usage. it's not entirely new as it was possible to find at least one script with overlapping functionality in the IUG repository, but I believe it's the first one that can do all of these:

Show the session owning most (if not all) temporary obkjects which can be:

Explicit (CREATE TEMP TABLE....) and inplicit (SELECT .. INTO TEMP...) temporary tables
Hash structures used by hash joins
Sort structures used by ORDER BY and GROUP BY clauses
Temporary structures resulting from view materialization, inline views and some OLAP functions

Show the temporary table structures (columns and respective datatypes and indexes, both explicit and system created)
Find the objects created by the currently running query and other opened cursors
Ability to work on secondary read-only servers

The script is hopefully simple to use. As with most of my scripts the "-h" option shows the help:

galileo@solstice.onlinedomus.net:informix-> ixtempuse -h
ixtempuse: -V | -h | [-s <session> [-t temp_table]] [-u <user>] [-d <database>] [-D <dbspace> [-I max_iterators]
          -V shows script version
          -h shows this help
          -s <session list>       : Show information for a session or list of sessions (separated by commas)
          -t <temp_table>         : Show temporary table structure for a single session/table (ALL for all)
          -u &ltuser list>          : Show information for a user or list of users (separated by commmas)
          -d &ltdatabase list>      : Show information for sessions in a database or list of databases (separated by commas)
          -D &ltdbspace list>       : Show information for a dbspace or list of dbspaces (separated by commas - must be temp dbspaces)
          -I &ltmax_iterators list> : The script can generate an infinite recursion if something goes wrong.
                                      To prevent this there's a limit of 100 iterators that can be overriden with this parameter
                                      But be advices that in most cases if the limit is reached, it means the script as a flaw.
                                      Apart a script bug, this situation should only happen on very complex queries which are unlikely
                                      to appear frequently. Overriding the limit may cause a FORK BOMB!!!
Ex: ixtempuse -s 43,35,4
galileo@solstice.onlinedomus.net:informix->

Without arguments it shows an overview of tthe temporary space usage:

galileo@solstice.onlinedomus.net:informix-> ixtempuse
+----------+------------------+----------+-------------------+--------------------------+-------------------+----------+----------+
|Sessionid |Username          |PID       |Conn Time          |DBSpace                   |   # (H/G/S/T/V)   |DBSpace MB|Session MB|
+----------+------------------+----------+-------------------+--------------------------+-------------------+----------+----------+
|55         informix           22522      2016-09-21 12:36:58|dbtemp1                   |11 /0  /0  /0  /0  |22.5      |          |
|                                                            |dbtemp2                   |11 /0  /0  /0  /0  |22.0      |          |
|                                                            |                          |                   |          |44.5      |
+------------------------------------------------------------+--------------------------+-------------------+----------+----------+
|52         informix           22348      2016-09-21 12:28:42|dbtemp2                   |0  /0  /0  /0  /1  |10.62     |          |
|                                                            |                          |                   |          |10.62     |
+------------------------------------------------------------+--------------------------+-------------------+----------+----------+
|99         informix           29367      2016-09-21 16:17:00|dbtemp1                   |0  /0  /0  /1  /0  |0.01      |          |
|                                                            |dbtemp2                   |0  /0  /0  /1  /0  |0.01      |          |
|                                                            |rootdbs                   |0  /0  /0  /1  /0  |0.01      |          |
|                                                            |                          |                   |          |0.04      |
+------------------------------------------------------------+--------------------------+-------------------+----------+----------+
galileo@solstice.onlinedomus.net:informix-&gt

Using the "-s" option we can get the detail for one or more sessions:

galileo@solstice.onlinedomus.net:informix-> ixtempuse -s 55
-----------------------------------------------------------------------------------------------------------------------------------
SID: 55       User: informix      Client: solstice.onlinedomus.net     PID: 22522
Connected at: 2016-09-21 12:36:58
-----------------------------------------------------------------------------------------------------------------------------------
  DBSPACE: dbtemp1
    H: th_build_ffffffffffffffff                                                        (2097154/0x00200002) 2MB
    H: th_build_ffffffffffffffff                                                        (2097155/0x00200003) 2.25MB
    H: th_build_ffffffffffffffff                                                        (2097156/0x00200004) 2MB
    H: th_build_ffffffffffffffff                                                        (2097157/0x00200005) 2MB
    H: th_build_ffffffffffffffff                                                        (2097158/0x00200006) 2MB
    H: th_build_ffffffffffffffff                                                        (2097159/0x00200007) 2MB
    H: th_probe_ffffffffffffffff                                                        (2097160/0x00200008) 2.25MB
    H: th_probe_ffffffffffffffff                                                        (2097161/0x00200009) 2MB
    H: th_probe_ffffffffffffffff                                                        (2097162/0x0020000a) 2MB
    H: th_probe_ffffffffffffffff                                                        (2097163/0x0020000b) 2MB
    H: th_probe_ffffffffffffffff                                                        (2097164/0x0020000c) 2MB
    Total space for object of type H in this dbspace: 22.5MB
  Total space for DBSPACE dbtemp1 is 22.5MB:

  DBSPACE: dbtemp2
    H: th_build_ffffffffffffffff                                                        (3145730/0x00300002) 2MB
    H: th_build_ffffffffffffffff                                                        (3145731/0x00300003) 2MB
    H: th_build_ffffffffffffffff                                                        (3145732/0x00300004) 2MB
    H: th_build_ffffffffffffffff                                                        (3145733/0x00300005) 2MB
    H: th_build_ffffffffffffffff                                                        (3145734/0x00300006) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145735/0x00300007) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145736/0x00300008) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145737/0x00300009) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145738/0x0030000a) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145739/0x0030000b) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145740/0x0030000c) 2MB
    Total space for object of type H in this dbspace: 22MB
  Total space for DBSPACE dbtemp2 is 22MB:

Summary for space usage for session 55 is:
      Hash       : 44.5      MB      Groups BY  : 0MB
      Sort       : 0         MB      Temp Tables: 0MB
      Views      : 0         MB      Others     : 0MB
Total space for session 55 is 44.5MB

galileo@solstice.onlinedomus.net:informix->

and with the "-s" and "-t" option we can get the structure of the temporary tables within one session:

galileo@solstice.onlinedomus.net:informix-> ixtempuse -s 99 -t all
{ TABLE "informix"."fnunes_teste" row size = 85 number of columns = 1 index size = 31 }
CREATE TEMP TABLE "informix"."fnunes_teste"
(
        col1_decimal_14_not_null         DECIMAL(14) NOT NULL,
        col2_decimal_12_5_unique         DECIMAL(12, 5),
        col3_dt_year_to_second           DATETIME YEAR TO SECOND,
        col4_dt_year_to_month            DATETIME YEAR TO MONTH,
        col5_dt_year_to_day              DATETIME YEAR TO DAY,
        col6_dt_year_to_hour             DATETIME YEAR TO HOUR,
        col7_dt_year_to_minute           DATETIME YEAR TO MINUTE,
        col8_dt_year_to_second           DATETIME YEAR TO SECOND,
        col9_dt_day_to_day               DATETIME DAY TO DAY,
        col10_dt_houwr_to_hour           DATETIME HOUR TO HOUR,
        col11_dt_minute_to_minute        DATETIME MINUTE TO MINUTE,
        col12_dt_second_to_second        DATETIME SECOND TO SECOND,
        col13_dt_varchar_10              VARCHAR(10),
        col14_dt_varchar_10_5            VARCHAR(10)
);

CREATE INDEX ix_2 ON fnunes_teste (col14_dt_varchar_10_5, col1_decimal_14_not_null DESC);
CREATE INDEX ix_1 ON fnunes_teste (col13_dt_varchar_10);
CREATE UNIQUE INDEX 0_2 ON fnunes_teste (col2_decimal_12_5_unique);


{ TABLE "informix"."t_2" row size = 24 number of columns = 2 index size = 0 }
CREATE TEMP TABLE "informix"."t_2"
(
        col1                             INTEGER,
        col3                             CHAR(20)
);



{ TABLE "informix"."t_1" row size = 4 number of columns = 1 index size = 0 }
CREATE TEMP TABLE "informix"."t_1"
(
        col1                             INTEGER
);



galileo@solstice.onlinedomus.net:informix->

Getting the script

The script can be downloaded from http://github.com/domusonline/InformixScripts (browse through scripts/ix)
It's licensed under GPL 2.0, so feel free to use it and even change it if you want. I welcome any feedback, requests and bug reports.

Warnings and disclaimer

I have to be very clear on this section. First of all, this is my best effort to provide something useful and that can help customers (DBAs) in their daily routine, and hopefully help to reduce the number of PMRs that are opened around this topic. The script was tested in several combinations of OS (RHEL, HP-UX, Solaris, AIX) and different engine versions (11.50 and 12.10) and several use cases. But anyone using it will have to assume full responsibility for it's results and behavior. Having said this, I'd be very glad if users provide feedback and bug reports. Assuming I can reproduce it, I'd gladly fix it.
A few very important points:

The script is SLOW. There isn't much I can do about it because the way it works (and that's apparently the only way to get the info) means I must go through all the sessions and several onstat commands. I have plans to try to use a single execution of onstat (with -i) but I'm not sure if that's possible. Current workaround it to reduce the scope of the sessions it has to go through. It has options for session id (-s), user (-u) and database (-d). Naturally the slowness is proportional to the number of session and also to the complexity of what they're doing and what cursors they have opened
The script requires recursion and the only way I've found to make it work in KSH is to run the recursive function as a background process. As with any thing that is recursive there's always the possibility of an infinite loop. I had this during development and I created some measures to prevent it. The main one is that the script will only go up to 100 levels of recursion. This should be more than enough for most avergae day to day queries. A query that requires more than this means that it has more than 100 "iterators", where an iterator is a table scan, a nested loop join, a sort, a merge, an hash join etc. So as you can imagine, 100 should be enough. When the limit is reached the script stops. There's an option to increase the limit, but you should think twice (or more) before using it. An high value can lead to a FORK BOMB. Also, because of the recursion, the script may go over the limit of user processes you have defined. Currently I have no way around this.

Acknowledgements

I must publicly thank several people who somehow contributed to this script. A special thanks to Jacques Renaut from R&D who provided invaluable technical guidance, and allowed me to proceed when I was stuck trying to understand internal structures. Frank Arias, a technical support engineer was crucial in getting it to work on Solaris. Adelino Silva, another technical support engineer was the first beside me to test it and provided valuable input. Jonathan Leffler provided some important feedback. Finally two customers, one in Portugal who provided feedback on HP-UX and another in the US who was fundamental for solving Solaris specific issue.

Versão Portuguesa

Introducão

O Informix tem algumas pedras no sapato ou esqueletos no armário conforme preferirmos um termo ou outro.. Na minha opinião o que eu considero como tal pode ser falta de alguma funcionalidade, comportamento indesejado ou impossibilidade do DBA em obter informação necessária à sua atividade. Penso que abri RFEs (request for enhancements) para a maioria se não todos os casos, e os meus favoritos serão provavelmente:

Impossibilidade de facilmente verificar quem está a consumir espaço temporário (RFE 77879 e RFE 43877)
Impossibilidade de gerar um plano de execução de uma query que esteja a correr (RFE 33800)
Comportamento por omissão em bases de dados não ANSI, no que diz respeito à atribuição automática de privilégios (ou a falta de um equivalente à variável NODEFDAC mas configurável no $ONCONFIG - RFE 34407 e RFE 60849)

Os problemas para os quais abri dois RFEs deve-se ao facto de o primeiro ter sido recusado ou erroneamente (na minha opinião) considerado resolvido. Existem alguns outros problemas como o corte de strings em bases de dados não ANSI sem geração de erros, impossibilidade de utilizar PAM em clientes OLEDB - ainda que só com password -, falta do SID nos logs de audit etc....

Mas destes, o primeiro não parece ter tido nenhum progresso e penso que é uma limitação séria ao trabalho diário de um DBA. E mesmo que as equipas de I&D resolvessem implementar a funcionalidade hoje, provavelmente não seria portado para as versões anteriores. que serão suportadas por alguns anos ainda. Por outras palavras, mesmo que o problema fosse resolvido hoje, os clientes com versões anteriores continuariam a sofrer com o tema por muitos anos. E considerando que a IBM fechou a minha primeira tentativa de RFE, com base no fato de estarmos a trabalhar na limitação de utilização de recursos por sessão (incluindo o espaço temporário), duvido que este pedido venha a ser considerado prioritário. Como nota acessória, a funcionalidade de limitar os recursos foi muito bem vinda. Mas o facto de podermos configurar algo não elimina a necessidade de monitorizar. Diria que isto é senso comum

Solução via script e sua utilização

Bom, considerando tudo isto e depois de aprender mais algumas coisas sobre o motor, percebi que seria possível criar algo que ajudasse os clientes das versões existentes relativamente aos primeiros dois problemas acima referidos (uso de espaço temporário e plano de execução de uma query já a correr). De momento o que tenho numa forma que possa ser partilhada é um script que reporta a utilização de espaço temporário. O conceito não é totalmente novo e é possível encontrar pelo menos um script no repositório do IIUG que tem funcionalidade algo coincidente. Mas penso que este será o primeiro conseguir fazer tudo isto:

Mostrar a sessão que criou a maioria (se não todos) os tipos de estruturas temporárias, que podem ser:

Tabelas temporárias explícitas (CREATE TEMP TABLE....) e implícitas (SELECT .. INTO TEMP...)
Estruturas de Hash usadas pelos HASH joins
Estruturas de ordenação usadas pelos ORDER BY e GROUP BY
Estruturas temporárias resultantes da materialização de views, inline views, e algumas funções OLAP

Mostrar a estrutura das tabelas temporárias (colunas, respetivos tipos de dados e índices, quer os criados pelos utilizadores quer os criados pelo sistema para suporte de constraints)
Encontrar os objetos criados pela query em execução e por outros cursores abertos
Possibilidade de trabalhar em servidores secundários em modo de leitura apenas

O script deverá (espera-se) ser fácil de utilizar. Como na maioria dos meus scripts a opção "-h" mostra a ajuda:

galileo@solstice.onlinedomus.net:informix-> ixtempuse -h
ixtempuse: -V | -h | [-s <session> [-t temp_table]] [-u <user>] [-d <database>] [-D <dbspace> [-I max_iterators]
          -V shows script version
          -h shows this help
          -s <session list>       : Show information for a session or list of sessions (separated by commas)
          -t <temp_table>         : Show temporary table structure for a single session/table (ALL for all)
          -u &ltuser list>          : Show information for a user or list of users (separated by commmas)
          -d &ltdatabase list>      : Show information for sessions in a database or list of databases (separated by commas)
          -D &ltdbspace list>       : Show information for a dbspace or list of dbspaces (separated by commas - must be temp dbspaces)
          -I &ltmax_iterators list> : The script can generate an infinite recursion if something goes wrong.
                                      To prevent this there's a limit of 100 iterators that can be overriden with this parameter
                                      But be advices that in most cases if the limit is reached, it means the script as a flaw.
                                      Apart a script bug, this situation should only happen on very complex queries which are unlikely
                                      to appear frequently. Overriding the limit may cause a FORK BOMB!!!
Ex: ixtempuse -s 43,35,4
galileo@solstice.onlinedomus.net:informix->

Sem argumentos mostra o panorama geral da utilização de espaço temporário:

galileo@solstice.onlinedomus.net:informix-> ixtempuse
+----------+------------------+----------+-------------------+--------------------------+-------------------+----------+----------+
|Sessionid |Username          |PID       |Conn Time          |DBSpace                   |   # (H/G/S/T/V)   |DBSpace MB|Session MB|
+----------+------------------+----------+-------------------+--------------------------+-------------------+----------+----------+
|55         informix           22522      2016-09-21 12:36:58|dbtemp1                   |11 /0  /0  /0  /0  |22.5      |          |
|                                                            |dbtemp2                   |11 /0  /0  /0  /0  |22.0      |          |
|                                                            |                          |                   |          |44.5      |
+------------------------------------------------------------+--------------------------+-------------------+----------+----------+
|52         informix           22348      2016-09-21 12:28:42|dbtemp2                   |0  /0  /0  /0  /1  |10.62     |          |
|                                                            |                          |                   |          |10.62     |
+------------------------------------------------------------+--------------------------+-------------------+----------+----------+
|99         informix           29367      2016-09-21 16:17:00|dbtemp1                   |0  /0  /0  /1  /0  |0.01      |          |
|                                                            |dbtemp2                   |0  /0  /0  /1  /0  |0.01      |          |
|                                                            |rootdbs                   |0  /0  /0  /1  /0  |0.01      |          |
|                                                            |                          |                   |          |0.04      |
+------------------------------------------------------------+--------------------------+-------------------+----------+----------+
galileo@solstice.onlinedomus.net:informix-&gt

Usando a opção "-s" obtemos o detalhe de uma ou mais sessões:

galileo@solstice.onlinedomus.net:informix-> ixtempuse -s 55
-----------------------------------------------------------------------------------------------------------------------------------
SID: 55       User: informix      Client: solstice.onlinedomus.net     PID: 22522
Connected at: 2016-09-21 12:36:58
-----------------------------------------------------------------------------------------------------------------------------------
  DBSPACE: dbtemp1
    H: th_build_ffffffffffffffff                                                        (2097154/0x00200002) 2MB
    H: th_build_ffffffffffffffff                                                        (2097155/0x00200003) 2.25MB
    H: th_build_ffffffffffffffff                                                        (2097156/0x00200004) 2MB
    H: th_build_ffffffffffffffff                                                        (2097157/0x00200005) 2MB
    H: th_build_ffffffffffffffff                                                        (2097158/0x00200006) 2MB
    H: th_build_ffffffffffffffff                                                        (2097159/0x00200007) 2MB
    H: th_probe_ffffffffffffffff                                                        (2097160/0x00200008) 2.25MB
    H: th_probe_ffffffffffffffff                                                        (2097161/0x00200009) 2MB
    H: th_probe_ffffffffffffffff                                                        (2097162/0x0020000a) 2MB
    H: th_probe_ffffffffffffffff                                                        (2097163/0x0020000b) 2MB
    H: th_probe_ffffffffffffffff                                                        (2097164/0x0020000c) 2MB
    Total space for object of type H in this dbspace: 22.5MB
  Total space for DBSPACE dbtemp1 is 22.5MB:

  DBSPACE: dbtemp2
    H: th_build_ffffffffffffffff                                                        (3145730/0x00300002) 2MB
    H: th_build_ffffffffffffffff                                                        (3145731/0x00300003) 2MB
    H: th_build_ffffffffffffffff                                                        (3145732/0x00300004) 2MB
    H: th_build_ffffffffffffffff                                                        (3145733/0x00300005) 2MB
    H: th_build_ffffffffffffffff                                                        (3145734/0x00300006) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145735/0x00300007) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145736/0x00300008) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145737/0x00300009) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145738/0x0030000a) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145739/0x0030000b) 2MB
    H: th_probe_ffffffffffffffff                                                        (3145740/0x0030000c) 2MB
    Total space for object of type H in this dbspace: 22MB
  Total space for DBSPACE dbtemp2 is 22MB:

Summary for space usage for session 55 is:
      Hash       : 44.5      MB      Groups BY  : 0MB
      Sort       : 0         MB      Temp Tables: 0MB
      Views      : 0         MB      Others     : 0MB
Total space for session 55 is 44.5MB

galileo@solstice.onlinedomus.net:informix->

E com as opções "-s" e "-t" podemos obter a estrutura das tabelas temporárias criadas por uma sessão:

galileo@solstice.onlinedomus.net:informix-> ixtempuse -s 99 -t all
{ TABLE "informix"."fnunes_teste" row size = 85 number of columns = 1 index size = 31 }
CREATE TEMP TABLE "informix"."fnunes_teste"
(
        col1_decimal_14_not_null         DECIMAL(14) NOT NULL,
        col2_decimal_12_5_unique         DECIMAL(12, 5),
        col3_dt_year_to_second           DATETIME YEAR TO SECOND,
        col4_dt_year_to_month            DATETIME YEAR TO MONTH,
        col5_dt_year_to_day              DATETIME YEAR TO DAY,
        col6_dt_year_to_hour             DATETIME YEAR TO HOUR,
        col7_dt_year_to_minute           DATETIME YEAR TO MINUTE,
        col8_dt_year_to_second           DATETIME YEAR TO SECOND,
        col9_dt_day_to_day               DATETIME DAY TO DAY,
        col10_dt_houwr_to_hour           DATETIME HOUR TO HOUR,
        col11_dt_minute_to_minute        DATETIME MINUTE TO MINUTE,
        col12_dt_second_to_second        DATETIME SECOND TO SECOND,
        col13_dt_varchar_10              VARCHAR(10),
        col14_dt_varchar_10_5            VARCHAR(10)
);

CREATE INDEX ix_2 ON fnunes_teste (col14_dt_varchar_10_5, col1_decimal_14_not_null DESC);
CREATE INDEX ix_1 ON fnunes_teste (col13_dt_varchar_10);
CREATE UNIQUE INDEX 0_2 ON fnunes_teste (col2_decimal_12_5_unique);


{ TABLE "informix"."t_2" row size = 24 number of columns = 2 index size = 0 }
CREATE TEMP TABLE "informix"."t_2"
(
        col1                             INTEGER,
        col3                             CHAR(20)
);



{ TABLE "informix"."t_1" row size = 4 number of columns = 1 index size = 0 }
CREATE TEMP TABLE "informix"."t_1"
(
        col1                             INTEGER
);



galileo@solstice.onlinedomus.net:informix->

Obtenção do script

O script pode ser descarregado de http://github.com/domusonline/InformixScripts (navegue por scripts/ix) Está licenciado como GPL 2.0, pelo que é livre de utilizá-lo e até de o modificar caso deseje. Qualquer comentário, sugestão ou reporte de bug será muito bem vindo.

Avisos e termo de não responsabilização

Tenho de ser muito claro nesta secção. Antes de mais, isto resulta do meu melhor esforço em fornecer algo que possa ser útil aos clientes (DBAs) na sua rotina, e que eventualmente ajude a reduzir ou resolver os PMRs que vão sendo abertos em torno deste problema. O script foi testado em várias combinações de sistema operativo ((RHEL, HP-UX, Solaris, AIX) e diferentes versões do Informix (11.50 e 12.10) bem como em vários casos de uso. Mas qualquer pessoa que deseje utilizá-lo terá de assumir a responsabilidade pelo seu resultado e comportamneto. Tendo deixado isto claro estarei totalmente disponível para corrigir qualquer problema que consiga reproduzir e que me seja indicado pelos seus utilizadores.
Alguns pontos adicionais muito importantes:

O script é LENTO. Não há muito que possa fazer, porque a forma como funciona (e penso que é a única de obter a informação) requer que varra todas as sessões e execute uma série de comandos onstat para cada uma. Tenho planos de tentar fazer apenas uma execução do onstat (com a opção -i) mas não estou seguro que seja possível. A forma de minimizar a lentidão atualmente será reduzir o número de seeões a examinar. Tem opções para indicar uma lista de sessões (-s), utilizadores (-u) e bases de dados (-d). Naturalmente a lentidão será proporcional ao número de sessões e complexidade do que estejam a executar e dos cursores que tenham aberto
O script requer recursividade e a única forma que encontrei de o conseguir fazer em KSH é correr a função recursiva como um processo em background. Como em tudo o que envolva recursividade existe a possibilidade de entrarmos num ciclo infinito. Aconteceu-me durante o desenvolvimento e consequentemente crirei alguns mecanismos para o evitar. O principal é que por omissão o script só entrará em 100 níveis de recursão. Isto deverá ser mais que suficiente para a maioria das nossas queries do dia a dia. Uma query que necessite mais que isto terá de ter mais de 100 "iteradores", sendo um iterador um acesso a uma tabela, um nested loop join, um hasj join, um sort, um merge etc. Por isso, como se compreenderá, 100 deverá ser suficiente para a maioria dos casos. Quando o limite é atingido o script aborta Existe uma opção para aumentar o limite, mas deverá pensar várias vezes antes de a usar. Um valor muito alto pode causar um FORK BOMB!!!Adicionalmente, devido à recursividade, o script pode exceder o limite de processos definidos para o seu ambiente. Atualmente não há forma de evitar isto.

Agradecimentos

Tenho de agradecer publicamente a várias pessoas que de alguma forma contribuiram para o script. Um agradecimento muito especial para o Jacques Renaut do I&D que forneceu preciosa ajuda técnica que me permitiu prosseguir quando pensava estar "encalhado" durante as tentativas de interpretação das estruturas internas. O Frank Arias, do suporte técnico foi crucial na solução de problemas de execução em Solaris. O Adelino Silva, também do suporte técnico foi o primeiro depois de mim a testar o script e forneceu ideias e informação importantees. O Jonathan Leffler forneceu comentários muito úteis. E finalmente dois clientes, um em Portugal que forneceu feedback e tetses em HP-UX e outro nos EUA que foi fundamental para a solução de problemas específicos de Solaris