Sunday, December 12, 2010

Panther: Name service cache

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

English version:

A recent thread in the IIUG mailing list (relative to a reverse DNS issue) reminded me of a new Panther (version 11.7) functionality that was on my list for articles. I've been avoiding many of the bigger and more important features because they will take a lot of time to write about... I hope this one will be shorter.

Informix needs to read several files or interact with DNS servers each time you try to open a connection. Considering Unix and Linux (Windows is a bit different technically, but not that much conceptually), these are some of the actions the engine must do:
  1. Depending on your host resolution criteria it will probably open the /etc/hosts file to search for your client's IP address. If it's not there it will contact your DNS server in order to request the name associated with the IP address.
    Note that all this is done by a system call.
  2. It will access /etc/passwd (or equivalent) to get your user details (HOME dir, password - this is probably stored in another file like /etc/shadow - , user id, group id etc.)
The engine must also access /etc/services and /etc/group in other situations.
Depending on your environment these activities can take a bit of time, and require some significant CPU usage. There are systems with high number of connections per second which can naturally transform this into a significant issue.
To give you an example I do regular work on a system that used to receive a very large number of requests from CGI programs. So, each request received by HTTP required a new process on the application server, and a new connection on the database server. They had peaks of tens of requests per second. Currently they're using Fast CGI with noticeable improvements.
Anyway, IBM decided to give us the chance to optimize this by caching previous results (file searches and DNS requests). This is done with the new parameter called NS_CACHE (from Name Service Cache). The format of this $ONCONFIG parameter is:

host=num_secs,services=num_secs,user=num_secs,group=num_secs

Each comma separated pair (functionality=num_secs) configures the number of seconds that the engine will cache a query result for that functionality. I'm calling it functionality, because it can be implemented through files or system APIs. The documentation could be clearer, but let's check each one:
  • host
    This is the host and IP address resolution service. Depending on your system configuration (on most Unixes and Linux this is specified in /etc/nsswitch.conf) it can be resolved by reading the /etc/hosts file and/or making a request to your DNS servers
  • service
    This should be the map between service names and system ports, usually done by reading /etc/services. The only situation that comes to my mind where this is used is when you're trying to start a listener (either during engine startup or after that with onmode -P) or when you're trying to make a distributed query to another engine, and you use names in your INFORMIXSQLHOSTS instead of port numbers. In any case, I may be missing something...
  • user
    This is very important. It refers to all the user related info that Informix gathers from the OS and that is relevant to Informix. The information can be stored in /etc/passwd, /etc/shadow, or indirectly be managed by external services like LDAP. It can include:
    - Home dir
    - User ID
    - Group ID
    - Password
    - User status (enable or disable
  • group
    This relates to the OS group information. Usually done by reading /etc/group
If the specified number of seconds to cache the information is zero, it means that we don't want to cache it. So the behavior will be the old engine behavior (for each relevant request, the information must be obtained).
The parameter can be changed online with onmode -wm

It's important that you fully understand the implications of caching these kind of information. By asking Informix to cache this info, we're also assuming the risk of working with stale information. Let's imagine a simple scenario. Assume this sequence of events:
  1. At time T0 you connect using user and password to the engine which is setup to cache user information for 600s (10 minutes).
  2. At time T1 you change that user password
  3. At time T2, the same user tries to connect to the Informix database with the new password. It will fail!
  4. At time T3 (T0 + the number of seconds to cache user information) the user repeats the connection attempt with the new password. It will succeed!
How can you avoid situation 3? If you change the cache timeout to 0, it will work as a flush.
If for example you do some changes to your user's information you can run:


onmode -wm NS_CACHE="host=900,service=900,user=0,group=900"
onmode -wm NS_CACHE="host=900,service=900,user=900,group=900"


These commands will flush the user information cache, and then reactivate it.

So, the point I'd like to make is that this feature can help you improve performance (specially for systems with an high connection rate), but it can have some side effects. You can workaround these ones, but for that you must know they exist.


Versão Portuguesa:

Uma discussão recente na lista de correio do IIUG (relativa a um problema com reverse DNS) lembrou-me de uma funcionalidade nova do Panther (versão 11.7) que estava na minha lista de temas a abordar. Tenho andando a evitar muitas das maiores e mais importantes novidades porque vou demorar bastante tempo a escrever sobre elas.... Espero que esta seja mais reduzida.

O Informix tem de ler diversos ficheiros ou interagir com servidores de nomes (DNS) cada vez que abre uma conexão. Considerando o Unix e Linux (em Windows será um pouco diferente tecnicamente, mas não muito conceptualmente), estas são as acções que o motor tem de fazer durante o estabelecimento de uma conexão:

  1. Dependendo do critério usado para resolver endereços e nomes, provavelmente irá abrir o ficheiro /etc/hosts para procurar o IP da conexão. Se não o encontrar irá provavelmente contactar o servidor de nomes (DNS) e pedir o nome associado ao IP de onde chega a conexão.
    Note-se que isto é feito com uma chamada de sistema e não cabe ao Informix definir os critérios.
  2. Irá aceder ao /etc/passwd (ou equivalente) para obter os dados do utilizador (HOME dir, password - isto deve estar guardado noutro ficheiros como o /etc/shadow- , id de utilizador, id de grupo etc.)
O motor também tem de aceder ao /etc/services e /etc/group noutras situações.
Dependendo do seu ambiente estas operações podem demorar um pouco e requerer um consumo de CPU relevante. Existem sistemas com muitas conexões novas por segundo o que naturalmente pode transformar isto num problema sério.
Para dar um exemplo, trabalho regularmente com um sistema que em dada altura recebia um enorme número de pedidos por CGI. Sendo CGI, cada pedido recebido via HTTP requeria um novo processo na máquina do servidor aplicacional, e uma nova conexão na base de dados. Tinham picos de dezenas de ligações por segundo. Actualmente estão a usar Fast CGIs com benefício notórios.
De qualquer forma a IBM decidiu dar aos utilizadores a oportunidade de optimizarem estes aspectos, através de uma cache que guarda respostas anteriores (pesquisas em ficheiros e resultados de DNS). Isto é feito com um novo parâmetro designado NS_CACHE (de Name Service Cache). O formato do parâmtro do $ONCONFIG é:

host=num_segs,services=num_segs,user=num_segs,group=num_segs

Cada par (funcionalidade=num_segs) separado por vírgula, configura o número de segundos durante os quais o motor irá manter em cache o resultado de uma pesquisa para essa funcionalidade. Estou a chamar-lhe "funcionalidade", porque pode ser implementada usando ficheiros ou APIs de sistema. A documentação deveria ser mais clara, mas vamos ver cada uma:
  • host
    O serviço de resolução de nomes e endereços IP. Conforme a configuração do seu sistema (na maioria dos Unixes e Linux isto é definido em /etc/nsswitch.conf) pode ser resolvido pelo ficheiro /etc/hosts ou fazendo um pedido aos servidores de DNS
  • service
    Este é o mapeamento entre o nome de serviços e as portas de sistema, habitualmente feito através da leitura do ficheiro /etc/services. As únicas situações que me ocorrem em que isto é usado é quando arrancamos com um listener (seja no arranque do motor ou depois quando se usa o onmode -P), ou quando tentamos executar uma query distríbuida a outro motor, e usamos nomes no nosso INFORMIXSQLHOSTS em vez de números de portos. Mas pode estar a escapar-me alguma coisa, e haver outras...
  • user
    Este é muito importante. Refere-se a toda a informação relativa aos utilizadores que o Informix obtém do sistema operativo e que é relevante para o Informix. A informação é guardada no /etc/passwd e /etc/shadow, ou gerida indirectamente em serviços externos como LDAP. Pode incluir:
    - Home dir
    - ID de utilizador
    - ID de grupo
    - Palavra passe
    - Estado do utilizador (activo, inactivo)
  • group
    Isto diz respeito à informação de grupos do sistema operativo. Normalmente feito por consulta ao ficheiro /etc/group

Se o número de segundos especificado para a cache for zero, significa que não queremos fazer caching. Portanto o comportamento será o antigo do motor (para cada pedido a informação tem de ser obtida).

O parâmetro pode ser modificado online com o comando onmode -wm

É importante que entenda completamente todas as implicações de fazer caching deste tipo de informação. Ao pedir ao Informix que guarde e reutilize a informação já obtida, estamos também a assumir o risco de trabalhar com informação entretanto desactualizada. Vamos imaginar um cenário simples. Consideremos a seguinte sequência de eventos:

  1. No momento T0 conectamo-nos usando um utilizador e palavra chave a um motor configurado para efectuar caching por 600 segundos (10 minutos).
  2. No momento T1 mudamos a palavra chave desse mesmo utilizador.
  3. No momento T2 o mesmo utilizador tenta conectar-se ao Informix usando a nova palavra chave. Vai falhar!
  4. No momento T3 (T0+ o número de segundos configurado para a cache de utilizador) o utilizador repete a tentativa de acesso com a nova palavra chave. Vai ter sucesso!
Como pode evitar a situação do ponto 3? Se mudar o tempo de cache para 0, funciona como uma limpeza da cache.
Se por exemplo efectuar mudanças na informação dos utilizadores, pode executar:


onmode -wm NS_CACHE="host=900,service=900,user=0,group=900"
onmode -wm NS_CACHE="host=900,service=900,user=900,group=900"


Estes comandos fazem a limpeza da informação e depois re-activam a cache.

Portanto, o ponto que gostaria de frisar é que esta funcionalidade pode melhorar o desempenho (especialmente em sistemas com elevada frequência de novas conexões), mas também pode ter efeitos secundários. Estes podem ser contornados, mas para isso temos de saber que existem.

Wednesday, November 10, 2010

Quiz game / Adivinha

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

English version:

If you have 15m I'd like to propose you a quiz game. Go to this webpage:

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

scroll down to the white papers section and open the one titled "Smart Systems Require an Embedded Database: Six Criteria to Consider"
It's a joint IBM and Cisco whitepaper that talks about the characteristics a database should have to be used as an embeddable database. The characteristics are analyzed through six criteria: installation, integration, performance, resource management, administration and availability.
If you know what have been introduced in Informix in the latest releases you'll find this quite amusing. So what's the quiz? Try to find out what database the paper is talking about. I don't need to tell you the answer, mainly because you'll surely find out by yourself, but also because the answer is discreetly given at the end of the paper...
It's public that some Cisco equipments include Informix (Cisco support forums support this claim). I personally believe this is enough proof that Informix is an excellent product if you need to embed a database in your solution (whether it is software only or software and hardware). If you take some time to check the latest versions new features you'll find lots of improvements for this type of use.



Versão Portuguesa:

Se tiver 15m livres gostava de lhe propor um jogo de adivinha. Vá até esta página:

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

desça até à secção dos white papers e abra o intitulado "Smart Systems Require an Embedded Database: Six Criteria to Consider" (apenas em Inglês)
É um documento conjunto entre a IBM e a Cisco que fala sobre as características que uma base de dados deve ter para ser usada como uma base de dados embebida. As características são analisadas segundo seis critérios: instalação, integração, desempenho, gestão de recursos, administração e disponibilidade.
Se sabe o que tem sido introduzido no Informix nas últimas versões, vai achar este documento divertido. Portanto qual é a adivinha? Tente descobrir qual é a base de dados falada no documento. Não necessito de lhe dar a resposta aqui, principalmente porque conseguirá perceber a resposta sozinho, mas também porque a resposta é dada de forma muito discreta no final do documento...
É público que alguns equipamentos Cisco incluem Informix (os fóruns de suporte da Cisco sustentam esta afirmação). Pessoalmente acredito que isto é prova suficiente de que o Informix é um excelente produto se necessita de embeber uma base de dados na sua solução (seja apenas de software ou software e hardware).
Se tirar algum tempo para verificar as novas funcionalidades das últimas versões encontrará imensas melhorias para este tipo de utilização.

Tuesday, November 2, 2010

IIUG 2011 Conference / Conferência IIUG 2011

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

English Version:

IIUG has just opened the 2011 IIUG conference registration. The conference will be held in May 15-18 2011, at the usual place, the Marriot Overland Park hotel in Overland Park, Kansas City. The conference can cost as little as:
  • $525 for the conference registration (if you register before January 31 and you're an IIUG member)
  • $129 / night (Sunday and week days) plus $99 / night (Friday and Saturday)
  • Travel costs
Regular sessions will be held from Monday to Wednesday and there are special Sunday sessions (tutorials). From Sunday evening to Tuesday, you'll have breakfast, lunch and evening receptions to keep you well fed. So a typical stay (arriving and Sunday afternoon and leaving on Thursday will cost you around $525 + (4 * $129) + travel costs + Wednesday dinner which translates into around $1050 plus travel costs.

That's what you'll pay. What about what you'll get? Well, I can speak for the 2010 conference. It was by far one of the best training events I've ever been. If you work with Informix, or plan to work with Informix you have several options for training: IBM classes, Instructor Led Online (remote online training), custom classes in your company installations and IIUG conference. And one thing I can assure you: You won't get the networking, knowledge transfer and the possibility to interact with the IBM Informix technical staff anywhere else. Typically my biggest problem was to decide which session to attend. And next year, with the recent launch of Panther (v11.7) the sessions should be even more interesting. You also get the chance to take free certification tests (around $150). Besides all this the conference atmosphere is rather amusing and you'll get a lot of fun. Maybe you should omit this from your management or they may prefer to take your place! :)

So if you have a training budget you should consider this. It's also a rare opportunity to speak to the people who drive Informix's future. If you need a new feature, or if you find a limitation in the product there is no better place to explain it than at the conference.

In short, you'll get:
  • More interesting sessions than you'll be able to attend (it's a good idea to take a colleague and each one attend a different session at a time)
  • Free certification tests
  • Opportunity to talk with all the Informix gurus out there
  • Opportunity to interact with the Informix top architects
  • Networking with other users. You can do and promote your business there
  • Relaxed, friendly and fun atmosphere promoted by all the IIUG people
  • Opportunity to understand why the conference takes place in Kansas City (no distractions besides the green fields and having the Informix lab right next door)
All this for maybe less than the cost of a traditional 3 day course

Finally, IIUG is still accepting speakers nominations (until November 15). If you have something to present, be it a deep dive into some particular aspect of Informix, a good use case, a success story etc. please don't hesitate. Speakers will not pay for the conference (less $525 on the budget). Don't hold back if you have something interesting to show. The audience will be friendly and your presentation skills will be less important than your subject.


Versão Portuguesa:

O IIUG anunciou a abertura do registo para a sua conferência internacional de utilizadores de 2011. A conferência terá lugar de 15 a 18 de Maio de 2011, no local habitual, o hotel Marriot Overland Park, em Overland Park, Kansas City, EUA. O custo poderá ser tão pouco quanto:

  • $525 para o registo na conferência (se se inscrever antes de 31 de Janeiro e for membro do IIUG)
  • $129 / noite (Domingo a quarta-feira) mais $99 / noite (Sexta-feira e Sábado)
  • Custos de viagem

As sessões normais decorrem de Segunda a Quarta-feira e existem sessões especiais no Domingo (tutorials). Do final de Domingo até Quarta-feira terá pequeno almoço, almoço e recepção nocturna para o manter bem alimentado. Assim, uma ida típica (chegada no Domingo ao final da tarde e saída na Quinta-feira) custar-lhe-á cerca de $525 + ( 4 * $129) + custos de viagem + jantar de Quarta-feira, o que se traduzirá em cerca de $1050 mais viagens.

Isto é o que custa. E quanto ao que se recebe? Bom, eu posso falar pela conferência deste ano (2010). Foi de longe um dos melhores eventos de formação em que estive. Se trabalha com Informix, ou se planeia trabalhar com Informix tem várias opções de formação: Cursos da IBM, Instructor Led Online (formação online remota), cursos customizados nas instalações da sua empresa e a conferência do IIUG. E algo posso garantir: Não vai obter a possibilidade de interacção, a transferência de conhecimentos e a possibilidade de interagir com o staff técnico da IBM Informix em mais lado nenhum. Regra geral a minha dificuldade foi escolher a sessão a que iria assistir no horário seguinte. E no ano que vem, com o recente lançamento da versão 11.7 (Panther) as sessões devem ser ainda mais interessantes. Também tem a possibilidade de fazer testes gratuitos de certificação (rondam os $150).
Para além disto, a atmosfera da conferência é bastante engraçada e divertida. Mas talvez seja melhor omitir isto à sua gestão, ou podem preferir tomar o seu lugar! :)

Portanto, se tem um orçamento de formação deve considerar isto. É também uma rara oportunidade de falar com as pessoas que decidem o futuro do Informix. Se precisa de uma nova funcionalidade ou se encontrou uma limitação no produto não há melhor sitio que a conferência para o explicar.

Em resumo obterá:

  • Mais sessões de interesse que aquelas a que conseguirá assistir (é uma boa ideia levar um colega e dividirem-se pelas sessões concorrentes no horário)
  • Testes de certificação gratuitos
  • Oportunidade de falar com todos os gurus de Informix
  • Oportunidade de interagir com os arquitectos de topo do Informix
  • Interacção com outros utilizadores. Pode efectuar e promover negócios lá
  • Atmosfera descontraída e divertida, promovida por todos os elementos do IIUG
  • Oportunidade de perceber porque é que a conferência se realiza em Kansas City (poucas distracções para além dos campos verdes, e ter o laboratório de Informix mesmo ao virar da esquina)
Tudo isto possivelmente por menos custo que um curso tradicional de 3 dias.

Por último, o IIUG ainda está a aceitar nomeações para apresentações (até 15 de Novembro de 2010). Se tem algo para apresentar, seja uma visão aprofundada de algum aspecto do Informix, um bom caso de utilizaçao, uma história de sucesso etc. por favor não hesite.
Os apresentadores não pagarão a conferência (menos $525 no orçamento). Não se retraia caso tenha algo interessante para apresentar. A audiência será amigável e as suas qualidades de apresentação serão menos importantes que o tema em si.

Sunday, October 31, 2010

Panther: EXISTS or NOT EXISTS

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

English version:

I'll continue with the quick and easy posts about Panther (v11.70). This time I'll focus on some new SQL that was added in Panther. Most (if not all) CREATE and DROP statements now allow for IF NOT EXISTS and IF EXISTS clauses respectively. These clauses allow us to write CREATE/DROP statements that will not raise errors in case the objects already exist and we're trying to create them, or when they don't exist and we're trying to drop them.
As an example:


panther@pacman.onlinedomus.net:fnunes-> onstat -

IBM Informix Dynamic Server Version 11.70.UC1 -- On-Line -- Up 00:03:17 -- 369588 Kbytes

panther@pacman.onlinedomus.net:fnunes-> dbaccess stores -

Database selected.

> DROP TABLE test;

206: The specified table (test) is not in the database.

111: ISAM error: no record found.
Error in line 1
Near character position 15
> DROP TABLE IF EXISTS test;
>

These two clauses can be used for TABLE, PROCEDURE, FUNCTION, DATABASE, INDEX, ROLE etc. (both for create and drop).
This can be used in scripts to prevent that they abort prematurely. Also interesting is the fact that this syntax can be found on mySQL. So it's easier now to port existing code into Informix.



Versão Portuguesa:

Vou continuar com os artigos rápidos e fáceis sobre a versão 11.70 (Panther). Desta vez vou abordar uma mudança no SQL que foi adicionada ao Panther. A maior parte (se não todas) as instruções CREATE e DROP suportam agora as cláusulas IF NOT EXISTS e IF EXISTS respectivamente. Estas cláusulas permitem-nos escrever instruções CREATE/DROP que não geram erros caso os objectos já existam e os estejamos a tentar criar, ou quando não existem e os estamos a tentar eliminar.
Como exemplo:


panther@pacman.onlinedomus.net:fnunes-> onstat -

IBM Informix Dynamic Server Version 11.70.UC1 -- On-Line -- Up 00:03:17 -- 369588 Kbytes

panther@pacman.onlinedomus.net:fnunes-> dbaccess stores -

Database selected.

> DROP TABLE test;

206: The specified table (test) is not in the database.

111: ISAM error: no record found.
Error in line 1
Near character position 15
> DROP TABLE IF EXISTS test;
>

Estas duas cláusulas podem ser usadas para TABLE, PROCEDURE, FUNCTION, DATABASE, INDEX, ROLE etc. (tanto para o CREATE como para o DROP).
Isto pode ser usado em scripts para evitar que abortem prematuramente. Também é interessante o facto de que esta sintaxe pode ser encontrada no mySQL. Portanto será agora mais fácil portar código existente para Informix

Friday, October 29, 2010

New blog from Paraguay

This article will only be written in English
Este artigo só tem versão Inglesa. Para ver esta notícia em Português consulte o site do Cesar Martins

There is a new south American blog, written in castilian. It's located here:

http://informixpy.blogspot.com/

The author is Javier Gray.
Apparently Javier wants to translate some articles from other blogs (he already did it once from Cesar's blog) besides writing his own articles. Javier also requested my permission to do the same from my blog. So, permission is granted as long as a reference to the original author is kept (as he did with Cesar's article). Hopefully, some of this blog's articles will be available in English, Portuguese and Castilian! That's great! Anybody wants to pick up for French and Chinese (and others?)

Thursday, October 21, 2010

Informix today: an executive statement / Informix hoje: Declaração de um executivo

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

English version:
I'm doing a pause in the Panther related articles to make echo of something equally important. The ones more involved in the Informix community surely recognize the name of Robert D. Thomas. He's an IBM executive, more precisely a vice president for Information Management and he has been addressing some communications to the Informix community.
He did it in March and he's doing it again
I won't repeat here what he writes in his latest letter, but I'd like to mention something about him. As you can see in both these letters and also on his session in IIUG conference in 2010, he always and I mean always starts his messages with a story. It may look strange but we must admit that it really works. It's like a signature. In this case, with a very short paragraph he condenses all the rest of his ideas. And it does sound good. I don't know if he digs these stories, or if he has someone to do it for him, or if he has a pocket reference of inspiring stories :).... How he does it, I don't know, but that he does it perfectly he does it.
The topic of this letter is the status of Informix, and how IBM has delivered (or not) on what Rob laid down in March.
Interesting read. You'll love the story.
I'll refrain myself of commenting on his statements, since any agreement would look suspicious and any disagreement could get me fired :)


Versão Portuguesa:

Estou a fazer uma pausa na série de artigos sobre o Panther, para fazer eco de algo igualmente importante. Quem esteja mais envolvido na comunidade Informix certamente reconhece o nome de Robert D. Thomas. É um executivo da IBM, mais precisamente o vice presidente para Information Management e tem endereçado algumas comunicações à comunidade.
Fê-lo em Março e está a fazê-lo agora
Não vou repetir o que escreve nesta sua última carta, mas gostava de mencionar algo sobre ele. Como pode confirmar por ambas as cartas e também na sua sessão na conferência anual do IIUG em 2010, ele começa sempre e repito sempre as suas mensagens com uma estória. Pode parecer estranho mas tenho de admitir que realmente funciona. É como uma assinatura. Neste caso, com um curto parágrafo condensa todas as ideias restantes. E soa bem. Não sei se ele pesquisa estas estórias, ou se tem alguém que o faça por ele, ou se tem uma referência de bolso com estórias inspiradoras :)... Não sei como o faz, mas garantidamente sai-lhe bem.
O tema desta carta é o estado do Informix, e como a IBM tem cumprido (ou não) com o que o Rob expôs em Março como sendo o caminho a seguir.
É uma leitura interessante. Vai adorar a estória.
Abstenho-me de comentar as suas afirmações pois qualquer concordância seria suspeita e qualquer discordância poderia fazer com que fosse despedido :)

Wednesday, October 20, 2010

Panther: "extenting" indexes / "extenting" indíces

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


English version:

Very short article for very simple feature: Since v11.7 (Panther) you can now define the extent size for indexes as we use to do with tables (data). Many people may find this a great feature, or a must have (specially if you worked with other RDBMS before), but for me it's relatively useless (unless it makes easier to port SQL scripts).
Why do I think this? Because Informix has been clever enough to find a good size for the index extents. It simply doesn't need us to tell it. It knows the size that the key will need for each index entry, and it knows the table's extent size. So it can calculate how many rows will fit in the data area (since it knows the extent size) and then it can calculate the space that number of rows will consume in the index.
I don't recall having a discrepancy between the index number of extents and the tables data extents. So I'm assuming it worked ok over the years.

The syntax is similar to the CREATE TABLE. But let's start by seeing how it works without specifying the index extent size:


panther_clone@pacman.onlinedomus.net:informix-> cat test_100k.sql
DROP TABLE test_100k;

CREATE TABLE test_100k
(
col1 INTEGER,
col2 CHAR(4)
) EXTENT SIZE 100 LOCK MODE ROW;

CREATE UNIQUE INDEX ix_test_100k ON test_100k(col1);
panther_clone@pacman.onlinedomus.net:informix-> dbaccess stores test_100k.sql

Database selected.


Table dropped.


Table created.


Index created.


Database closed.

panther_clone@pacman.onlinedomus.net:informix-> oncheck -pt stores:test_100k | awk '/Extents/,/^$/ {print $0}'
Extents
Logical Page Physical Page Size Physical Pages
0 4:4627 50 50

Extents
Logical Page Physical Page Size Physical Pages
0 4:4677 81 81


So, the data extent size of 100K generates an index extent size of 162K.
If we double the data extent size to 200K:


panther_clone@pacman.onlinedomus.net:informix-> cat test_200k.sql
DROP TABLE test_200k;

CREATE TABLE test_200k
(
col1 INTEGER,
col2 CHAR(4)
) EXTENT SIZE 200 LOCK MODE ROW;

CREATE UNIQUE INDEX ix_test_200k ON test_200k(col1);
panther_clone@pacman.onlinedomus.net:informix-> dbaccess stores test_200k.sql

Database selected.


Table dropped.


Table created.


Index created.


Database closed.

panther_clone@pacman.onlinedomus.net:informix-> oncheck -pt stores:test_200k | awk '/Extents/,/^$/ {print $0}'
Extents
Logical Page Physical Page Size Physical Pages
0 4:4758 100 100

Extents
Logical Page Physical Page Size Physical Pages
0 4:4858 162 162


So, doubling the data size doubles the index size.

What we can now do it establish the index extent size explicitly:


panther_clone@pacman.onlinedomus.net:informix-> cat test_100k_new.sql
DROP TABLE test_100k;

CREATE TABLE test_100k
(
col1 INTEGER,
col2 CHAR(4)
) EXTENT SIZE 100 LOCK MODE ROW;

CREATE UNIQUE INDEX ix_test_100k ON test_100k(col1) EXTENT SIZE 40 NEXT SIZE 162;
panther_clone@pacman.onlinedomus.net:informix-> dbaccess stores test_100k_new.sql

Database selected.


Table dropped.


Table created.


Index created.


Database closed.

panther_clone@pacman.onlinedomus.net:informix-> oncheck -pt stores:test_100k | awk '/Extents/,/^$/ {print $0}'
Extents
Logical Page Physical Page Size Physical Pages
0 4:4627 50 50

Extents
Logical Page Physical Page Size Physical Pages
0 4:4677 20 20


Truly simple and obvious. Hopefuly this will bring peace to some souls who think that this was needed. And let's hope people won't start making wrong calculations and choose wrong extent sizes.


Versão Portuguesa:

Um artigo muito curto para uma funcionalidade muito simples: A partir da versão 11.7 (Panther) podemos definir o tamanho de cada extent para os índices tal como fazemos para as tabelas (dados). Muita gente pode considerar esta como uma grande funcionalidade, ou algo mesmo necessário (especialmente se já trabalhou com outros RDBMS antes), mas eu considero-a relativamente inútil (a menos que facilite a transposição de scripts SQL).
Porque penso assim? Porque o Informix sempre foi esperto o suficiente para encontrar um bom valor para os extents dos índices. Simplesmente não necessita que lhe digamos. Ele sabe o tamanho da chave necessário a cada entrada do índice, e sabe o tamanho dod extents da tabela. Portanto pode calcular quantas linhas caberão na área de dados (pois sabe o tamanho do extent) e assim consegue calcular quantas páginas é que o índice irá necessitar para esse mesmo número de registos.
Não me recordo de ver discrepância entre o espaço no índice e o espaço dos dados. Só posso assumir que tem corrido bem ao longo dos anos.

A nova sintaxe será semelhante à do CREATE TABLE. Vejamos como funciona sem especificar:


panther_clone@pacman.onlinedomus.net:informix-> cat test_100k.sql
DROP TABLE test_100k;

CREATE TABLE test_100k
(
col1 INTEGER,
col2 CHAR(4)
) EXTENT SIZE 100 LOCK MODE ROW;

CREATE UNIQUE INDEX ix_test_100k ON test_100k(col1);
panther_clone@pacman.onlinedomus.net:informix-> dbaccess stores test_100k.sql

Database selected.


Table dropped.


Table created.


Index created.


Database closed.

panther_clone@pacman.onlinedomus.net:informix-> oncheck -pt stores:test_100k | awk '/Extents/,/^$/ {print $0}'
Extents
Logical Page Physical Page Size Physical Pages
0 4:4627 50 50

Extents
Logical Page Physical Page Size Physical Pages
0 4:4677 81 81


Um tamanho de 100K para o extent dos dados gera um extent para indíces de 162K
Se duplicarmos o extent de dados para 200K:


panther_clone@pacman.onlinedomus.net:informix-> cat test_200k.sql
DROP TABLE test_200k;

CREATE TABLE test_200k
(
col1 INTEGER,
col2 CHAR(4)
) EXTENT SIZE 200 LOCK MODE ROW;

CREATE UNIQUE INDEX ix_test_200k ON test_200k(col1);
panther_clone@pacman.onlinedomus.net:informix-> dbaccess stores test_200k.sql

Database selected.


Table dropped.


Table created.


Index created.


Database closed.

panther_clone@pacman.onlinedomus.net:informix-> oncheck -pt stores:test_200k | awk '/Extents/,/^$/ {print $0}'
Extents
Logical Page Physical Page Size Physical Pages
0 4:4758 100 100

Extents
Logical Page Physical Page Size Physical Pages
0 4:4858 162 162


Portanto, duplicando o tamanho para dados, automaticamene o motor aumenta o tamanho do índice na mesma proporção

Podemos agora tentar estabelecer o tamanho do extent do índice:



panther_clone@pacman.onlinedomus.net:informix-> cat test_100k_new.sql
DROP TABLE test_100k;

CREATE TABLE test_100k
(
col1 INTEGER,
col2 CHAR(4)
) EXTENT SIZE 100 LOCK MODE ROW;

CREATE UNIQUE INDEX ix_test_100k ON test_100k(col1) EXTENT SIZE 40 NEXT SIZE 162;
panther_clone@pacman.onlinedomus.net:informix-> dbaccess stores test_100k_new.sql

Database selected.


Table dropped.


Table created.


Index created.


Database closed.

panther_clone@pacman.onlinedomus.net:informix-> oncheck -pt stores:test_100k | awk '/Extents/,/^$/ {print $0}'
Extents
Logical Page Physical Page Size Physical Pages
0 4:4627 50 50

Extents
Logical Page Physical Page Size Physical Pages
0 4:4677 20 20


Completamente simples e óbvio. Esperemos que isto ajude a pacificar algumas almas que acham isto necessário. E também que as pessoas não comecem agora a calcular mal o espaço a alocar.

Wednesday, October 13, 2010

Panther: The beginning / Panther: O início

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

English version:

Around 2007, after IBM launched the version 11.10 (Cheetah), I wrote a series of articles focusing on several new features. I called it "Chetah spot by spot: ...". I wanted to do the same for Panther, but I have a big problem: What is a Panther? Does it have spots?! Kate Tomchik (IIUG board member), asked about this in Jerry Keesee's (Informix development director) Facebook profile... For me a Panther is a black variant of several animals (leopard, jaguar and possibly a mountain lion or cougar). So, although it may have spots, they're not very visible... So, in short, I don't have a nice title for these articles... it's a shame, but I think we can all live with that :)
So, I took a look at the Panther release notes and looked at the new features... Too many! Too good. Since this is the first article, I'll try to group them (giving some highlights) following my personal view:

  • Embeddability
    This version is the best Informix version ever in terms of ability to embed it into some controlled environment. Some features that contribute to this are: better install, several capabilities for cloning and deploying instances, more autonomic features, improved ability to control it in a programmable way (alarm codes, oninit return codes), storage provisioning etc.
  • Grid
    Imagine you have a large number of instances. And you need to run something in all of them (or a subset). How do you do it? With scripts.... Yes... I've done it... But now you can do it with "grid functionality". You just define the grid nodes (add/delete) and then you connect to the grid, run you SQL, and voilá.... This requires a lot more explanation, but it's that simple.
  • Performance
    As always, a new version is expected to run faster than it's predecessors. This can be done with code improvements and new features. Panther has both. To list a few, it has several Informix XPS features that were ported into Dynamic Server like XPS api (faster tables and indexes access times), Index Skip Scan, Multi Index Scan, improved light scans, push down hash joins (or Star joins), and a few others like Forest of Trees Indexes (FOT), DLL preload, improved name service connection time (NS_CACHE) etc.
  • Warehousing
    Well... I named a few in the performance group. But there are others, like fragment level statistics, more fragmentation schemes (interval, list), online fragment attach/detach for interval fragmentation scheme
  • Security
    This is one of my favorites... Users don't need to be recognized by the OS anymore, trusted context was ported from DB2 (change the authentication inside an already established session - perfect for application servers, and hopefully in the future for 4GL web services), and finally the ability to audit only specific tables (when using the RDRW, INRW, DLRW and UPRW mnemonics). This last one was the Achilles' heel of the Informix auditing facility
  • Others
    It's weird to group such nice features into an "others" category, but I'll do it anyway for simplification: End of extent limit, online table reorg, WebSphere MQ datablade enhancements, OAT enhancements (too match all the relevant new features), DDL support for "CREATE/DROP ... IF [NOT] EXISTS", DDL on secondary nodes, Enterprise Replication without primary key, connection manager improvements, SPL debugging, Optim Development Studio and IBM Mashup Center 2.0 included, etc.
The next article will focus on the installation process. After that I'll proceed with several other features. Don't expect a specific order. I thought about going for the more important features first, but then I realized that there are excellent features in totally different areas. What can be fundamental to some people may as well be nearly useless to others... So, the order will not reflect the feature importance.


Versão Portuguesa:

Em 2007, após a IBM ter lançado a versão 11.10 (Cheetah), eu escrevi uma série de artigos que focavam várias funcionalidades novas. Na altura, só em Inglês, chamei-lhes "Chetah spot by spot: ..." que se poderiam traduzir por "Cheetah, mancha por mancha". Queria fazer algo semelhante para a nova versão com o nome de código "Panther" ou pantera mas deparei-me com um problema: O que é uma pantera? Tem manchas? A Kate Tomchik, perguntou sobre isto no profile do Jerry Keesee (director de desenvolvimento do Informix) no Facebook... Para mim, uma pantera é uma variante negra de vários animais (leopardo, jaguar e possivelmente leão da montanha ou puma). Portanto, embora possa ter manchas serão pouco visíveis.... Em resumo, não tenho um título sonante para estes artigos... é uma pena, mas penso que conseguimos viver sem isso :)

Continuando, dei uma vista de olhos nas release notes do Panther à procura das novas funcionalidades... Muitas e muito boas. Sendo este o primeiro artigo, vou tentar agrupá-las (salientando algumas) seguindo a minha visão pessoal:

  • Embeddability
    Esta é a melhor versão Informix de sempre em termos de capacidade de embeber a base de dados num ambiente controlado. Algumas funcionalidades contribuem para isto: Melhor instalação, várias formas de clonar e "implantar" instâncias, mais funcionalidades autonomicas, melhoria nas possibilidades de controlar as instâncias de forma programática (códigos de alarme, códigos de retorno do oninit), aprovisionamento de espaço etc.
  • Grid
    Imagine que tem um grande número de instâncias. E que necessita executar algo em todas elas (ou numa parte). Como é que o faz? Com scripts... sim... já o fiz... Mas agora pode fazê-lo com a funcionalidade "grid". Só tem de definir os nós do grid (adicionar/remover) e depois conectar-se à grid correr o SQL e voilá.... Isto requer muito mais explicações, mas é assim tão simples...
  • Desempenho
    Como sempre, espera-se que uma nova versão seja mais rápida que as anteriores. Isto pode ser feito com melhorias no código ou novas funcionalidades. O Panther tem ambas. Só para listar algumas, tem várias funcionalidades que foram portadas do Informix XPS para o Dynamic Server como a XPS api (melhores tempos de acesso a tabelas e indíces), Index Skip Scan, Multi Index Scan, melhoria nos light scans, push down hash joins (ou Star Joins) e mais algumas como indíces Forest Of Trees (FOT), pré-carregamento de DLLs, melhores tempos do serviço de nomes (NS_CACHE) etc.
  • Warehousing
    Bom.... Já mencionei algumas no grupo de desempenho. Mas existem outras, como estatisticas ao nível dos fragmentos (ou partições), mais formas de framentação/particionamento (intervalo, lista), attach/detach de fragmentos online para tabelas particionadas por intervalo
  • Segurança
    Este é um dos meus favoritos.... Os utilizadores já não necessitam de ser reconhecidos pelo sistema operativo (note-se que a autenticação já podia ser feita externamente, mas os utilizadores tinham de ter a sua identidade - uid, home dir, group etc. - conhecido pelo SO), trusted context foi portado do DB2 (mudar a autenticação dentro de uma conexão já estabelecida - perfeito para servidores aplicacionais, e esperemos no futuro para os web services em 4GL), e finalmente a possibilidade de auditar tabelas específicas (quando se quer usar as menemónicas RDRW, INRW, DLRW e UPRW). Esta última era o calcanhar de Aquiles do sistema de auditing do Informix
  • Outros
    É estranho agrupar estas funcionalidades tão interessantes numa categoria "Outros" mas faço-o para simplificar: Fim do limite de extents, reorganização (junção de extents) de tabelas online, melhorias no datablade WebSphere MQ, melhorias no Open Admin Tool (para acompanhar as novas funcionalidades do motor), suporte para a sintaxe "CREATE/DROP ... IF [NOT] EXISTS", DDL nos nós secundários, Enterprise Replication sem chave primária, melhorias no connection manager, depuramento de stored procedures SPL, Optim Development Studio e IBM Mashup Center 2.0 incluído etc.

O próximo artigo focará o processo de instalação. Depois prosseguirei com várias outras funcionalidades. Não espere uma ordem específica. Pensei em abordar primeiro as funcionalidades mais importantes, mas depois tomei consciência que há excelentes novidades em áreas completamente distintas. O que pode ser fundamental para um cliente pode ser praticamente inútil para outro. Assim a ordem não reflectirá a importância das funcionalidades

Tuesday, October 12, 2010

Panther is out / Panther está disponível

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

English version:

The new release of Informix (v11.70) is out and available on Passport Advantage. The announcement letter is here:

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=877&letternum=ENUSZP10-0472

Later I'll focus on the new features. For now you can read the announcement letter and check it on PA.

Versão Portuguesa:

A nova versão do Informix (v11.70) foi anunciada e está disponível no Passport Advantage. O anúncio oficial está aqui:

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=877&letternum=ENUSZP10-0472

Mais tarde irei abordar as novas funcionalidades. Por agora pode ler o anúncio e aceder ao produto no PA

Wednesday, October 6, 2010

Happy birthday... / Feliz aniversário

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

English version:

I'm really not very good with dates. I keep forgetting them. Today I was reviewing some of the blog links and structure, and one date poped up: September 26 of 2006. Around four years ago I made the first post in this blog. During these four years I believe I've made some interesting posts here (apologies for the lack od modesty), and judging by some feedback I have received some of this posts were important for my readers. That's the best reward I could get.
On that first post I explained some of the reasons why I was creating a blog. And these were:

  1. The only blog I've found about Informix seems empty
  2. I've been involved with Informix technology for several years and I think the Informix community although enthusiastic is a bit invisible
  3. I have some subjects about which I'd like to write a bit...
It's with great pleasure that I see that 1) and 2) aren't valid anymore. As you can see from the lists of links on the right side, we have a healthy blog community. We also have a strong international user group, and new user groups are appearing around the world (China, Adria, Brazil...)

One thing has not changed: I still have some subjects about which I'd like to write a bit. History is a funny thing and tends to repeat itself. Around 2006 we were preparing Cheetah which was released in 2007. Then came Cheetah 2 (2008). We're now waiting for Panther.

So I hope you enjoy the links/blogs revision and stay tuned for upcoming articles. Let's hope I have the time for everything I want to publish

Versão Portuguesa:

Não sou nada bom com datas. É habitual esquecer-me dos aniversários dos amigos (e até mesmo do meu!). Hoje estava a rever a lista de links e blogs e uma data saltou-me à vista: 26 de Setembro de 2006. Há cerca de quatro anos atrás eu coloquei o primeiro artigo neste blog. Durante estes quatro anos escrevi alguns artigos interessantes (modéstia à parte) e a julgar por algumas reacções que recebi, alguns desses artigos foram importantes para os meus leitores. Essa é a melhor recompensa que poderia ter.

Nesse primeiro artigo eu indiquei as razões porque estava a criar um blog. E estas eram:

  1. O único blog que encontrei sobre Informix parecia vazio
  2. Estava envolvido com a tecnologia Informix há já vários anos e parecia-me que a comunidade Informix, apesar de entusiasta, parecia invisível.
  3. Tinha vários assuntos sobre os quais queria escrever...
É com grande prazer que vejo que 1) e 2) já não são válidos. Como se pode ver pela lista de à direita, temos uma comunidade de blogs bastante saudável. Também temos um grupo internacional de utilizadores forte, e novos grupos locais têm aparecido (China, Adria, Brasil...)

Algo que não mudou: Ainda tenho vários assuntos sobre os quais desejo escrever. A história costuma repetir-se. Por volta de 2006 estávamos a preparar a versão Cheetah que foi lançada em 2007. Depois veio a Cheetah 2 (2008). Agora estamos à espera do Panther.

Assim, espero que aprecie a revisão dos links/blogs e mantenha-se alerta aos próximos artigos. Espero que tenha tempo suficiente para tudo o que pretendo publicar.

Wednesday, September 22, 2010

Have you met ROI and TCO? / Já conhece o ROI e o TCO?

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

English Version:

ROI and TCO are two well known IT buzzwords. They mean Return On Investment and Total Cost of Ownership (check the links for more technical descriptions). The first one tries to measure how much you earn or lose by investing on something (software product or solution in IT world). The second one tries to be a measure of the sum of costs you have when you decide to buy and use a software product or solution. For the technical staff these two measures are not the most important aspects. Usually we just like or dislike a product period!
But the decisions and choices usually aren't done by technical staff. Today the decisions are taken by people who have tight budgets and that need to show to corporate management that they are using the company's money properly. In other words, people who do and must care about TCO and ROI.
And many times we hear that Informix is nice technically (easy to work with, robust, scalable etc.), but that it's hard to convince higher management to use it (there are still ghosts from the past and FUD spread by competition).

Well, now we have two consulting firms studies precisely about these two topics.

The first comes from Forrester Consulting and analyses the costs, benefits and ROI of implementing Informix. Needless to say it concludes that you actually can save money while investing in Informix, and it explains why. The study was based on a real company.

The second come from ITG group and compares the TCO of Informix vs Microsoft SQL Server for mid sized companies. It's based on a survey with ten's of participants and the conclusions are, as you might expect, favorable to Informix (important to note that MS SQL Server has a reputation of being "economic", so we could let us think that it would be even better for other competitors)

The studies can be freely obtained from IBM website, and as usual you need to fill some data. I know, I know.... this is always annoying and we could arguably consider that this should be only a link to allow quick access to that, but honestly it will take one minute to fill the form, and you have the usual option to request that you won't be bothered (no emails, phone calls etc.)
Don't let it discourage you. The studies are well worth the effort. Their URLs are:

Finally, take notice that these studies used Informix 11.50. And we're getting closer to Panther which has lot's of improvements and some of them will certainly have impact on the running costs (less burden for the DBAs)


Versão Portuguesa:

ROI e TCO são duas palavras muito em voga no mundo das TI. Qurem dizer Return On Investment (Retorno do investimento) e Total Cost of Ownership (Custo total da posse) (verifique os links para explicações mais técnicas - e ainda mais detalhadas na versão Inglesa). O primeiro tenta medir quanto se ganha ou perde ao investir em algo (produto ou solução de software no mundo das TI). O segundo tenta ser uma medida da soma de custos que teremos quando decidimos usar um produto ou solução de software. Para o pessoal técnico estas medidas não são os aspectos mais importantes. Normalmente nós apenas gostamos ou não e ponto final!
Mas as decisões e escolhas normalmente não são feitas pelo pessoal técnico. Hoje em dia as decisões são tomadas por pessoas que têm orçamentos apertados e que sentem a necessidade de mostrar à administração das empresas que estão a usar o dinheiro da companhia criteriosamente. Por outras palavras, pessoas que se preocupam e devem preocupar com o TCO e ROI.
E muitas vezes ouvimos dizer que o Informix é muito bom tecnicamente (simples, fácil de usar, fiável etc.), mas que é difícil convencer a gestão a usá-lo (ainda existem fantasmas do passado e FUD espalhado pela concorrência)-


Bom, mas agora temos dois estudos de duas empresas de consultoria precisamente sobre estes tópicos.

O primeiro vem da Forrester Consulting e analisa os custos, benefícios e ROI de implementar Informix. Escusado será dizer que concluí que na realidade estamos a poupar dinheiro ao investir em Informix, e explica porquê. O estudo foi baseado num caso real.

O segundo vem da ITG Group e compara o TCO do Informix vs Microsoft SQL Server para médias empresas. É baseado num inquérito com dezenas de participantes e as conclusões são, como seria de esperar, favoráveis ao Informix (é importante notar que o MS SQL Server tem a reputação de ser "económico", por isso poderíamos deixar-nos pensar que seria ainda mais favorável comparando com outros concorrentes)

Os estudos podem ser obtidos gratuitamente no website da IBM, e como é habitual necessitamos de preencher alguns dados. Sim, eu sei, eu sei.... Isto é sempre irritante e é discutível de não deveria ser apenas uma questão de clicar num link para aceder aos estudos, mas honestamente não demora mais de um minuto a preencher o formulário e tem as opções habituais para que não sejamos incomodados (nada de emails ou chamadas telefónicas etc.)
Não deixe que isso o desencorage. Os estudos merecem bem este pequeno esforço. Os seus endereços são:

Finalmente, note-se que estes estudos incidiram no Informix 11.50. E estamos a aproximarmo-nos da versão Panther que trará muitas melhorias e algumas delas terão certamente impacto nos custos de utilização (menos carga para os DBAs)

Tuesday, September 7, 2010

Let's optimize / Vamos optimizar

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

English version.

In this article I'll show you a curious situation related to the Informix query optimizer. There are several reasons to do this. First, this is a curious behavior which by itself deserves a few lines. Another reason is that I truly admire the people who write this stuff... I did and I still do some programming, but my previous experience was related to business applications and currently it's mostly scripts, small utilities, stored procedures etc. I don't mean to offend anyone, but I honestly believe these two programming worlds are on completely different leagues. All this to say that a query optimizer is something admirable given the complexity of the issues it has to solve.

I also have an empiric view or impression regarding several query optimizers in the database market. This impression comes from my personal experience, my contact with professionals who work with other technologies and some readings... Basically I think one of our biggest competitors has an optimizer with inconstant behavior, difficult to understand and not very trustworthy. One of the other IBM relational databases, in this case DB2, has probably the most "intelligent" optimizer, but I have nearly no experience with it. As for Informix, I consider it not the most sophisticated (lot of improvements in V10 and V11, and more to come in Panther), but I really love it for being robust. Typically it just needs statistics. I think I only used or recommended directives two times since I work with Informix. And I believe I never personally hit an optimizer bug (and if you check the fix lists in each fixpack you'll see some of them there...)
To end the introduction I'd like to add that one of my usual tasks is query optimizing... So I did catch a few interesting situations. As I wrote above, typically an UPDATE statistics solves the problem. A few times I saw situations where I noticed optimizer limitations (things could work better if it could solve the query another way), or even engine limitations (the query plan is good, but the execution takes unnecessary time to complete). The following situation was brought to my attention by a customer who was looking around queries using a specific table which had a reasonable number of sequential scans.... Let's see the table schema first:

create table example_table
(
et_id serial not null ,
et_ts datetime year to second,
et_col1 smallint,
et_col2 integer,
et_var1 varchar(50),
et_var2 varchar(50),
et_var3 varchar(50),
et_var4 varchar(50),
et_var5 varchar(50),
primary key (et_id)
)
lock mode row;

create index ids_example_table_1 on example_table (et_timestamp) using btree in dbs1


And then two query plans they manage to obtain:


QUERY: (OPTIMIZATION TIMESTAMP: 08-25-2010 12:31:56)
------
SELECT et_ts, et_col2
FROM example_table WHERE et_var2='LessCommonValue'
AND et_col1 = 1 ORDER BY et_ts DESC


Estimated Cost: 5439
Estimated # of Rows Returned: 684
Temporary Files Required For: Order By

1) informix.example_table: SEQUENTIAL SCAN

Filters: (informix.example_table.et_var2 = 'LessCommonValue' AND informix.example_table.et_col1 = 1 )


So this was the query responsible for their sequential scans. Nothing special. The conditions are on non indexed fields. So no index is used. It includes an ORDER BY clause, so a temporary file to sort is needed (actually it can be done in memory, but the plan means that a sort operation has to be done).
So, nothing noticeable here... But let's check another query plan on the same table. In fact, the query is almost the same:


QUERY: (OPTIMIZATION TIMESTAMP: 08-25-2010 12:28:32)
------
SELECT et_ts, et_col2
FROM example_table WHERE et_var2='MoreCommonValue'
AND et_col1 = 1 ORDER BY et_ts DESC


Estimated Cost: 5915
Estimated # of Rows Returned: 2384

1) informix.example_table: INDEX PATH

Filters: (informix.example_table.et_var2 = 'MoreCommonValue' AND informix.example_table.et_col1 = 1 )

(1) Index Name: informix.ids_example_table_1
Index Keys: et_ts (Serial, fragments: ALL)


Ok... It's almost the same query, but this time we have an INDEX path.... Wait... Didn't I wrote that the conditions where not on indexed column(s)? Yes. Another difference: It does not need a temporary file for sort (meaning that it's not doing a sort operation). Also note that there are no filter applied on the index. So, in this case it's doing a completely different thing than on the previous situation. It reads the index (the whole index), accesses the rows (so it gets them already ordered) and then applies the filters discarding the rows that do not match. It does that because it wants to avoid the sort operation. But why does it change the behavior? You might have noticed that I already included a clue about this. To protect data privacy, I changed the table name, table fields and the query values. And in the first query I used "LessCommonValue" and on the second I used "MoreCommonValue". So as you might expect, the value on the second query is more frequent in the table than the value of the first query. How do we know that? First, by looking at the number of estimated rows returned (684 versus 2384). How does it predict this values? Because the table has statistics, and in particular column distribution. Here are them for the et_var2 column (taken with dbschema -hd):


Distribution for informix.example_table.et_var2

Constructed on 2010-08-25 12:19:04.31216

Medium Mode, 2.500000 Resolution, 0.950000 Confidence


--- DISTRIBUTION ---

( AnotherValue )


--- OVERFLOW ---

1: ( 4347, Value_1 )
2: ( 4231, Value_2 )
3: ( 3129, MoreCommonValue )
4: ( 2840, Value_4 )
5: ( 2405, Value_5 )
6: ( 3854, Value_6 )
7: ( 3941, Value_7 )
8: ( 2086, Value_8 )
9: ( 4086, Value_9 )
10: ( 4144, Value_10 )
11: ( 4086, Value_11 )
12: ( 2666, Value_12 )
13: ( 2869, Value_13 )
14: ( 3245, Value_14 )
15: ( 2811, Value_15 )
16: ( 3419, Value_16 )
17: ( 2637, Value_17 )
18: ( 3187, Value_18 )
19: ( 4347, Value_19 )
20: ( 898, LessCommonValue )
21: ( 4144, Value_20 )
22: ( 2260, Value_21 )
23: ( 3999, Value_22 )
24: ( 1797, Value_23 )
25: ( 2115, Value_24 )
26: ( 2173, Value_25 )
27: ( 4144, Value_26 )


If you're not used to look at this output I'll describe it. The distributions are showed as a list of "bins". Each bin, except the first one, contains 3 columns: The number of record it represents, the number of unique values within that bin, and the highest value within that bin. The above is not a good example because the "normal" bin values has only one (AnotherValue) and given it's the first one it means it's the "lowest" value in the column. Let's see an example from the dbschema description in the migration guide:


( 5)
1: ( 16, 7, 11)
2: ( 16, 6, 17)
3: ( 16, 8, 25)
4: ( 16, 8, 38)
5: ( 16, 7, 52)
6: ( 16, 8, 73)
7: ( 16, 12, 95)
8: ( 16, 12, 139)
9: ( 16, 11, 182)
10: ( 10, 5, 200)


Ok. So, looking at this we could see that the lowest value is 5, and that between 5 and 11 we have 16 values, 7 of them are unique. Between 11 and 17 we have 6 unique values etc.

Going back to our example we see an "OVERFLOW" section. This is created when there are highly repeated values that would skew the distributions. In these cases the repeated values are showed along the number of times they appear.

So, in our case, the values we're interested are "LessCommonValue" (898 times) and "MoreCommonValue" (3129 times). So with these evidences we can understand the decision to choose the INDEX PATH. When the engine gets to the end of the result set it's already ordered. And in this situation (more than 3000 rows) the order by would be much more expensive than for the other value (around 800 rows).

It's very arguable if the choice is effectively correct. But my point is that it cares... Meaning it goes deep in it's analysis, and that it takes into account many aspects, and is able to decide to use a query plan that it's not obvious (and choose it for good reasons).


Versão portuguesa:

Neste artigo vou mostrar uma situação curiosa relacionada com o optimizador de queries do Informix. Há várias razões para fazer isto. Primeiro porque é um comportamento interessante que por si só merece umas linhas. Outra razão é que eu admiro verdadeiramente as pessoas que escrevem este componente.... Eu fiz e ainda faço alguma programação, mas a minha experiência anterior estava relacionada com aplicações de negócio e actualmente é essencialmente scripts, pequenos utilitários, stored procedures etc. Não querendo ofender ninguém, mas honestamente acredito que estes dois mundos de programação estão em campeonatos completamente diferentes. Tudo isto para dizer que o optimizador é algo admirável dada a complexidade dos problemas que ele tem de resolver.

Também tenho uma visão empírica ou apenas uma impressão relativamente a alguns optimizadores no mercado de bases de dados. Esta impressão deriva da minha experiência pessoal, do meu contacto com profissionais que trabalham com outras tecnologias e de alguma leitura... Basicamente penso que o nosso maior competidor tem um optimizador com um comportamento insconstante, difícil de entender e pouco confiável. Uma das outras bases de dados relacionais da IBM, DB2 neste caso, tem provavelmente o optimizador mais "inteligente", mas não tenho practicamente nenhuma experiência com ele. No caso do Informix, considero que não é o mais sofisticado (muitas melhorias na versão 10 e 11, e mais no Panther), mas realmente adoro a sua robustez. Tipicamente apenas precisa de estatísticas. Julgo que só utilizei ou recomendei optimizer directives duas vezes desde que trabalho com Informix. E que me lembre nunca bati pessoalmente num bug do optimizador (embora baste consultar a lista de correcções de cada fixpack para sabermos que eles existem).
Para terminar esta introdução gostaria de referir que uma das minhas tarefas habituais é a optimização de queries. Por isso já encontrei algumas situações interessantes. Como escrevi acima, tipicamente um UPDATE STATISTICS resolve o problema. Algumas vezes encontrei limitações do optimizador (as coisas poderiam correr melhor se ele pudesse resolver as queries de outra maneira) e até limitações do motor (o plano de execução gerado é bom, mas a execução leva tempo desnecessário a correr). A situação que se segue chegou-me à atenção através de um cliente que estava a analisar queries sobre uma tabela que estava a sofrer muitos sequential scans.... Vejamos a definição da tabela primeiro:
create table example_table
(
et_id serial not null ,
et_ts datetime year to second,
et_col1 smallint,
et_col2 integer,
et_var1 varchar(50),
et_var2 varchar(50),
et_var3 varchar(50),
et_var4 varchar(50),
et_var5 varchar(50),
primary key (et_id)
)
lock mode row;

create index ids_example_table_1 on example_table (et_timestamp) using btree in dbs1


E agora dois planos de execução que obtiveram:


QUERY: (OPTIMIZATION TIMESTAMP: 08-25-2010 12:31:56)
------
SELECT et_ts, et_col2
FROM example_table WHERE et_var2='ValorMenosComum'
AND et_col1 = 1 ORDER BY et_ts DESC


Estimated Cost: 5439
Estimated # of Rows Returned: 684
Temporary Files Required For: Order By

1) informix.example_table: SEQUENTIAL SCAN

Filters: (informix.example_table.et_var2 = 'ValorMenosComum' AND informix.example_table.et_col1 = 1 )


Esta era uma das queries responsável pelos sequential scans. Nada de especial. As condições da query incidem em colunas não indexadas. Portanto não utiliza nenhum indíce. Inclui uma cláusula ORDER BY, por isso um necessita de "ficheiros" temporários para ordenação. (na verdade pode ser feito em memória, mas o plano quer dizer que precisa de fazer uma operação de ordenação).
Portanto nada a salientar aqui.... Mas vejamos o outro plano sobre a mesma tabela. Na verdade a query é muito semelhante:


QUERY: (OPTIMIZATION TIMESTAMP: 08-25-2010 12:28:32)
------
SELECT et_ts, et_col2
FROM example_table WHERE et_var2='ValorMaisComum'
AND et_col1 = 1 ORDER BY et_ts DESC


Estimated Cost: 5915
Estimated # of Rows Returned: 2384

1) informix.example_table: INDEX PATH

Filters: (informix.example_table.et_var2 = 'ValorMaisComum' AND informix.example_table.et_col1 = 1 )

(1) Index Name: informix.ids_example_table_1
Index Keys: et_ts (Serial, fragments: ALL)

Ok... É quase a mesma query, mas desta vez temos um INDEX PATH... Um momento!.... Não escrevi que as condições não indiciam sobre colunas indexadas? Sim. Outra diferença: Neste caso não necessita de "temporary files" (o que significa que não está a fazer ordenação). Note-se ainda que não existe nenhum filtro aplicado ao indíce. Portanto, neste caso está a fazer algo completamente diferente da situação anterior. Lê o indíce (todo o indíce), acede às linhas (assim obtém-nas já ordenadas) e depois aplica os filtros descartando as linhas que não verificam as condições. Faz isto porque pretende evitar a operação de ordenação. Mas porque é que muda o comportamento? Poderá ter reparado que já inclui uma pista sobre isto. Para proteger a privacidade dos dados mudei o nome da tabela, dos campos e dos valores das queries. E no primeiro caso utilizei "ValorMenosComum" e no segundo usei "ValorMaisComum". Portanto como se pode esperar, o valor da segunda query é mais frequente na tabela que o valor usado na primeira query. Como sabemos isso? Primeiro olhando para o valor estimado de número de linhas retornadas pela query (684 vs 2384). Como é que o optimizador prevê estes valores? Através das estatísticas da tabela, em particular as distribuições de cada coluna. Aqui estão as mesmas para a coluna et_var2 (obtidas com dbschema -hd):

Distribution for informix.example_table.et_var2

Constructed on 2010-08-25 12:19:04.31216

Medium Mode, 2.500000 Resolution, 0.950000 Confidence


--- DISTRIBUTION ---

( OutroValor )


--- OVERFLOW ---

1: ( 4347, Value_1 )
2: ( 4231, Value_2 )
3: ( 3129, ValorMaisComum )
4: ( 2840, Value_4 )
5: ( 2405, Value_5 )
6: ( 3854, Value_6 )
7: ( 3941, Value_7 )
8: ( 2086, Value_8 )
9: ( 4086, Value_9 )
10: ( 4144, Value_10 )
11: ( 4086, Value_11 )
12: ( 2666, Value_12 )
13: ( 2869, Value_13 )
14: ( 3245, Value_14 )
15: ( 2811, Value_15 )
16: ( 3419, Value_16 )
17: ( 2637, Value_17 )
18: ( 3187, Value_18 )
19: ( 4347, Value_19 )
20: ( 898, ValorMenosComum )
21: ( 4144, Value_20 )
22: ( 2260, Value_21 )
23: ( 3999, Value_22 )
24: ( 1797, Value_23 )
25: ( 2115, Value_24 )
26: ( 2173, Value_25 )
27: ( 4144, Value_26 )


Para o caso de não estar habituado a analisar esta informação vou fazer uma pequena descrição da mesma. As distribuições são mostradas como uma lista de "cestos". Cada cesto, excepto o primeiro, contém 3 colunas: O número de registo que representa, o número de valores únicos nesse cesto e o valor mais "alto" nesse cesto. O que está acima não é um bom exemplo porque a secção de "cestos" normal só tem um valor (OutroValor), e dado que é o primeiro apenas tem o valor, o que significa que é o valor mais "baixo" da coluna. Vejamos um exemplo retirado da descriçao do utilitário dbschema no manual de migração:


( 5)
1: ( 16, 7, 11)
2: ( 16, 6, 17)
3: ( 16, 8, 25)
4: ( 16, 8, 38)
5: ( 16, 7, 52)
6: ( 16, 8, 73)
7: ( 16, 12, 95)
8: ( 16, 12, 139)
9: ( 16, 11, 182)
10: ( 10, 5, 200)


Portanto olhando para isto podemos ver que o valor mais baixo é 5, que entre 5 e 11 temos 16 valores, 7 dos quais são únicos. Entre 11 e 17 temos 6 valores únicos etc.

Voltando à nossa situação concreta vemos uma secção de "OVERFLOW". Esta secção é criada quando há valores altamente repetidos que iriam deturpar ou desequilibrar as distribuições. Nestes casos os valores repetidos são mostrados lado a lado com o número de vezes que aparecem.

Assim, no nosso caso, estamos interessados nos valores "ValorMenosComum" (898 vezes) e "ValorMaisComum" (3129 vezes). Portanto, com estas evidências podemos perceber a decisão de escolher o INDEX PATH. Quando o motor chega ao final do conjunto de resultados o mesmo já está ordenado. E nesta situação (mais de 3000 linhas) a ordenação consumiria mais recursos qeu para a outra situação em análise (cerca de 800 linhas).


Pode ser muito discutivel se a decisão é efectivamente correcta. Mas o que quero salientar é que o optimizador se preocupa.... Ou seja, a análise que faz das condições e opções é profunda e é capaz de escolher um plano de execução que não é óbvio (e escolhê-lo por boas razões).

Sunday, August 29, 2010

Briug / Briug :)

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

Versão Portuguesa

Normalmente começo com a versão Inglesa, mas desta vez tinha naturalmente de começar com a versão Portuguesa. E como já terão reparado o título do artigo está igual em ambas as linguas. O que quer dizer BRIUG? Simples, Brazilian Informix Users Group. E pronto, está o artigo acabado... Não. Ainda não.... Falta dizer que foi criado o grupo Brasileiro de utilizadores de Informix, já tem um website ( http://www.briug.org/ ) e que quem está de momento a dar a cara e o trabalho pelo mesmo é o Miguel Carbone, bem conhecido na comunidade, entre outras coisas porque faz parte do board of directors do International Informix Users Group (IIUG) e o César Martins, autor do blog sobre Informix em http://www.imartins.com.br/informix/
Naturalmente o grupo vai contar com o apoio e colaboração de outras caras conhecidas da comunidade no Brasil e não só. Estou a recordar-me do Vagner Pontes, do Alexandre Marini (muito activo na mailing list do IIUG), do Pedro Henriques.... Temo esquecer-me de alguém.
Tive o privilegio de conhecer pessoalmente algumas destas pessoas durante a conferência anual do IIUG e o que posso dizer é que estou confiante que o assunto está bem entregue.

Do lado de cá do Atlântico vão os votos de muito sucesso, e muito contentamento por ver uma organização deste tipo num País que fala Português. Espero que apesar da distância também nós em Portugal possamos usufruir de algumas iniciativas que o novo grupo venha a desenvolver. E naturalmente quando for necessário uma maõzinha cá estaremos para o que for possível.

English Version:

I usually start by the English version, but this time I had to change. If you noticed, the article title is the same in English and Portuguese... So what is BRIUG? It means Brazilian Informix Users Group... I probably could end the article here, since it's easy to guess what happened, but I must write a few more words... So the Brazilian Informix Users are starting a new user group, and they already have a website ( http://www.briug.org/ ), and for now the people behind it are Miguel Carbone, a well known guy in the community (member of the International Informix Users Group - IIUG - board of directors) and César Martins, author of the Informix blog at http://www.imartins.com.br/informix/.
Naturally the group counts on the support and colaboration of other well known faces of the Brazilian Informix community like Vagner Pontes, Alexandre Marini (very active in the IIUG mailing list), Pedro Henriques.... I'm afraid I'll forget someone...
I had the pleasure of meeting some of these guys during the IIUG annual meeting and I'm convinced that the matter is in good hands.

From this side of the Atlantic ocean, I send my wishes of great success and I'm very happy to see the birth of an organization like this in a Portuguese speaking country.
I hope that despite the distance we in Portugal can take advantage of some of the initiatives that the new group develop in the future. Ans obviously, when you need an helping hand, we're here to do whatever is possible.

Friday, August 27, 2010

Out of support? Not yet! / Fora de suporte? Ainda não

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

English Version:

I hope that you had the chance to listen to the latest Chat with the Labs web conference. The topic was really interesting, specially if you're running Informix 7.31, 9.4 or 10. As you should know all these versions are out of support (v10 will be by the end of September). In this call, IBM announced (or re-announced) three options for support of these versions:

  1. Upgrade Bridge
    • This is just for 7.31
    • Has costs
    • Requires active subscription and support (S&S)
    • Client must have plans for upgrade
    • Can't be sold by partners
    • Doesn't provide R&D access or new fixes development
    • Provides severity 1 critical responses (systems down)
  2. Continuing Support (Pilot)
    • This is for version 9.4 and v10
    • Is included in active subscription and support (S&S)
    • Can be sold by partners, since it's included in S&S
    • Doesn't provide R&D access or new fixes development
    • Provides severity 1 critical responses (systems down)
    • Will end on September 2011 (1 year duration)
  3. Service extension
    • This can be acquired for any unsupported version
    • Has costs
    • Requires active subscription and support (S&S)
    • Can't be sold by partners
    • Provides access to R&D and new fixes development
    • Provides severity 1 critical response (systems down)
So, what does it all mean? Well, it really depends on your current version and your future plans:
  • For 7.31 (bridge) means that if you want to migrate, IBM will support you during the time it takes, and can also help you do the upgrade (separate cost). Note that you need to have upgrade plans.
    If you hit a new bug (one that has no fix for 7.31 or that is unknown), you're stuck with it. If you have a system down situation you will get help.
  • For versions 9.40 and 10, it means that you'll have one more year of support, included in the regular maintenance fee. Note that again, if you hit a new bug (either really new, or one that has no fix in versions 9.40 or 10) you'll have to live with it
    The good news is that you just need active maintenance (S&S)
  • For any version, if you really need access to new fixes (new bugs, or bugs to which there was no fixpack available with the fix), you can request the service extension. Note that this has charges besides the normal S&S cost.
So, the Continuing Support (Pilot) offer means you gained one more year to plan and do an upgrade, while keeping the ability of asking for help in case something goes wrong. Is this good? I believe the answer is yes if you're running one of those versions. But I personally have mixed feelings regarding this. Let's see:

  1. Ending support of a product version is always risky, since you may cause customer dissatisfaction
  2. Ending support of a product version can lead the customer to consider alternatives from competitors (If I have to migrate, why don't I choose another software....?)
  3. Keeping endless support for a product is negative for the software supplier for a number of (good) reasons:
    • It costs money (resources, source code maintenance, some bugs can be fixed in one way in newer versions, but have to be dealt with differently in older versions)
    • It keeps your customers away from new features and improved product uses
    • Increases the chances that customers favor the competition, because many times they compare the old version of a product from X with a newer version of a product from Y
  4. Having old product versions is bad for customers because:
    • Increases exposure to old bugs and security issues
    • Limits the ability to move to more recent platforms (hardware and operating systems)
    • Decreases your team members motivation (typically people like to work with new features, and they feel happy to learn new stuff)
  5. Upgrades are good for software suppliers and partners because:
    • Typically they are drivers for new sales of products and services
    • They are opportunities to get involved with the customers
    • They are opportunities to transfer knowledge and improve customer satisfaction and awareness
    • They can be drivers to new opportunities (cross sell anyone?)
  6. Upgrades are good for customers because:
    • They have the chance to improve product use
    • They are able to use new features
    • They can move to newer, better and cheaper platforms
    • They can gain new knowledge
  7. Upgrades can bin risky because you may face new problems, bugs or human errors
All this are advantages and disadvantages to use current software versions. I tried to be absolutely honest and objective (you can judge that and add or emphasize some of the points above). But in general, I'm in favor of keeping up to date with the current versions. Obviously you need to be careful, and stability has to be a value to preserve. But keeping yourself in software versions that are out of support or that will be out of support in a near future is no way to go. Do your upgrades, and do them well. I honestly suggest to everyone that is using 9.4 or 10 to take this new opportunity, and plan your upgrades in the next year. Each environment is different, but I've been very happy with latests 11.50 fixpacks.

So, please, check the web conference files (slides and audio - when available), if you have questions check the contact details, and then plan, plan, plan, test, test, test and upgrade!
I truly believe you'll be very happy with the improvements that IBM have been putting into IDS (and if you want to learn more about the future, check the Panther beta program)



Versão Portuguesa:

Espero que tenha tido oportunidade de assistir à última conferência web da série Chat with the Labs. O tópico foi verdadeiramente interessante, especialmente de estiver a utilizar o Informix 7.31, 9.40 ou 10. Como deve saber, estas versões estão sem suporte (a versão 10 ficará no final de Setembro próximo).
Nesta apresentação a IBM anunciou (ou re-anunciou) três opções para suporte destas versões:
  1. Upgrade Bridge
    • Apenas para a versão 7.31
    • Tem custos
    • Necessita de subscrição e suporte activa (S&S)
    • Cliente tem de possuir plano de upgrade
    • Não pode ser vendido por parceiros
    • Não permite acesso ao desenvolvimento nem a novas correcções
    • Disponibiliza suporte a problemas de severidade 1 (sistemas parados)
  2. Continuing Support (Pilot)
    • Disponível para as versões 9.40 e 10
    • Está incluinda na manutenção (subscrição e suporte - S&S)
    • Pode ser vendida por parceiros pois está incluída na manutenção
    • Não permite acesso ao desenvolvimento nem a novas correcções
    • Disponibiliza suporte a problemas de severidade 1 (sistemas parados)
    • Termina em Setembro de 2011 (duração de um ano)
  3. Extensão de serviço ou suporte extendido
    • Pode ser adquirido para qualquer versão já sem suporte
    • Tem custos
    • Necessita de manutenção (subscrição e suporte - S&S)
    • Não pode ser vendido por parceiros
    • Não permite acesso ao desenvolvimento nem a novas correcções
    • Disponibiliza suporte a problemas de severidade 1 (sistemas parados)
Portanto, o que é que tudo isto significa? Bem, depende da sua versão actual e dos seus planos para o futuro:

  • Para a 7.31 (bridge) significa que se quiser migrar, a IBM irá fornecer suporte durante o tempo que demorar, e pode até ajudar na migração (custos separados). Note-se que terá de ter planos de upgrade
    Se encontrar um novo bug, (um que não tenha correcção na linha 7.31 ou que seja desconhecido) não lhe será dada solução. Se tiver uma situação de sistema parado ser-lhe-á prestada ajuda.
  • Para as versões 9.40 e 10 (Continuing Support Pilot) significa que terá mais um ano de suporte, incluído na prestação de manutenção regular. Note-se novamente que se encontrar um novo bug (seja realmente novo, ou um para o qual não exista nenhum fixpack nas versões 9.40 ou 10 que inclúa a correcção) terá de viver com o mesmo
    A boa (excelente?) notícia é que só precisa de ter a manutenção (S&S) activa
  • Para qualquer versão, se quer mesmo ter acesso a todas as possibilidades do suporte (incluindo novos fixes) pode contratar a extensão de suporte. Note-se que isto tem custos adicionais ao custo normal de manutenção
Assim, a oferta Continuing Support Pilot significa que ganhou mais um ano para planear e efectuar o upgrade, mantendo entretanto a possibilidade de pedir ajuda caso alguma coisa corra mal. Isto é bom? Penso que a resposta é sim, mas tenho sentimentos contraditórios e pessoais sobre o assunto:

  1. Terminar o suporte a uma versão de um produto é sempre um risco, pois pode causar insatisfação dos clientes
  2. Terminar o suporte a uma versão de um produto pode levar um cliente a considerar alternativas da concorrência ( se sou obrigado a migrar, porque não hei-de escolher outro software?)
  3. Manter o suporte por tempo indeterminado ou muito longo é negativo para o fornecedor de software por várias (boas?) razões:
    • Custa dinheiro (recursos, manutenção do código fonte, alguns bugs podem ser corrigidos de uma maneira nas versões correntes, mas terem de ser corrigidos de maneira diferente em versões mais antigas)
    • Leva os clientes a não utilizarem novas funcionalidades e não tirarem o melhor partido do que o produto (actual) permite
    • Aumenta as hipóteses de os clientes favorecerem a concorrência, porque muitas vezes compara-se uma versão antiga do produto X com uma versão actual do produto Y
  4. Manter versões antigas de produtos é mau para os clientes porque:
    • Aumenta a exposição a bugs antigos e falhas de segurança
    • Limita a possibilidade de migração para plataformas mais actuais (hardware e sistema operativo)
    • Aumenta a desmotivação nas equipas de TI (tipicamente as pessoas gostam de trabalhar com as novas funcionalidades e ficam satisfeitas por adquirir novos e mais actuais conhecimentos
  5. Migrações de versões podem ser boas para os fornecedores de software e seus parceiros porque:
    • Tipicamente são pretexto para novas vendas de produtos e serviços
    • Providenciam oportunidades de criar e manter um maior envolvimento com os clientes
    • São oportunidades para haver transferência de conhecimento e melhorar a satisfação e reconhecimento dos clientes
    • Podem ser pretexto para novas oportunidades noutras áreas de negócio (cross sell)
  6. Migrações de versões são boas para os clientes porque:
    • São uma oportunidade de melhorar a utilização e exploração dos produtos
    • Permitem o uso das novas funcionalidades
    • Permitem migrar para plataformas mais recentes, melhores e mais económicas
    • Permitem adquirir novos conhecimentos
  7. Migrações de versões acarretam riscos porque se pode encontrar novos problems, bugs ou erros humanos
Tudo isto são vantagens e desvantagens de se manter em versões actualizadas do software. Tentei ser absolutamente honesto e objectivo (pode julgar por si, adicionar e relativizar a importância dos vários pontos). Mas em geral, sou a favor de nos mantermos em versões correntes. Naturalmente temos de ter cuidados, e a estabilidade dos ambientes deve ser um valor a preservar. Mas deixar-se cair em versões sem suporte, ou que irão ficar sem suporte num futuro próximo, não é um caminho correcto. Faça os seus upgrades e faça-os bem. Honestamente, sugiro a todos os utilizadores que estejam em versões 9.40 ou 10 que aproveitem esta oportunidade e planeiem as migrações durante o próximo ano. Cada ambiente é um caso específico, mas tenho tinho muito boas experiências com os últimos fixpacks da versão 11.50

Assim, por favor, consulte os ficheiros da conferência web (slides e áudio - quando disponível), se tiver questões consulte os contactos incluídos, e planeie, planeie, planeie, teste, teste, teste e migre!
Julgo sinceramente que ficará bastante satisfeito com as melhorias que a IBM tem incluído no Informix (e se quiser saber mais sobre o futuro veja o programa beta da versão Panther)