OLAP Window Functions

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 mention  some new functionality in 12.1, but I'll use that to answer a recent question on IIUG mailing list. The question initially posted was about when did Informix update the index involved in a transaction. But after a few interactions with the original poster, it was clear what the problem was and it's a bit tricky:
The user was UNLOADing a table that contained a primary key and there were duplicate records (regarding the primary key) in the result set. This naturally looks like a bug, but there is a technical explanation for that. Let's describe a simple reproduction. For that I wrote three simple SQL scritps that will be run through dbaccess:

#-------- main.sql
DROP TABLE IF EXISTS test;
CREATE TABLE test
(
        col1 INTEGER,
        col2 INTEGER,
        col3 CHAR(2000),
        PRIMARY KEY (col1,col2)
)
EXTENT SIZE 16 NEXT SIZE 16
LOCK MODE ROW;

INSERT INTO test VALUES ( 1, 1, 'a');
INSERT INTO test VALUES ( 1, 2, 'a');
INSERT INTO test VALUES ( 1, 3, 'a');
INSERT INTO test VALUES ( 1, 4, 'a');
INSERT INTO test VALUES ( 1, 5, 'a');

BEGIN WORK;
UPDATE TEST SET COL3 = 'a1' WHERE col1 = 1 AND col2 = 3;
!/bin/sleep 30
COMMIT WORK;


#-------- unload.sql
SET LOCK MODE TO WAIT;
UNLOAD TO test.unl
SELECT *, ROWID FROM test;

#-------- move_rows.sql
BEGIN WORK;
DELETE FROM test WHERE col1 = 1 AND col2 = 1;
INSERT INTO test VALUES (1, 1, 'b');
COMMIT WORK;

The first script, called "main.sql" will create a table, with row level locking and a particularity that helps the reproduction: Each page will contain only one row. I did this on Linux where the default page size is 2KB. If you run it on AIX (4KB pages) please change the col3 definition to CHAR(4000). Then the script will populate the table with 5 rows. Note that I'm using a composite primary key, but a simple primary key or any unique index should be enough.
Then I start a transaction and do an update on row "3" and just after that I run an external command to sleep for 30 seconds before executing the COMMIT. This gives me plenty of time to run the other scripts in parallel.

Next script is called "unload.sql" and it simply runs an UNLOAD of that table after setting the LOCK MODE TO WAIT. As you may expect this script will be stuck on the lock created by the first one.

The third script has the "magic". It DELETEs a row with a certain primary key and INSERTs it again, but with a different col3 value.
I will use the following SHELL script to run the reproduction scripts:

#!/bin/bash
dbaccess stores main.sql 1>main.out 2>&1 &
sleep 5
dbaccess stores unload.sql 1>unload.out 2>&1 &
sleep 5
dbaccess stores move_rows.sql 1>move_rows.out 2>&1 &
wait

So... It runs the "main.sql" in background. Sleeps for 5 seconds (enough so that the "main.sql" is able to enter the sleep after locking record 3). Then is launches the "unload.sql" script which will be waiting on the first one, also in the background. And then it runs the script that DELETEs and INSERTs a row with a certain primary key.

This is the resulting unload file:
1|1|a|257|
1|2|a|513|
1|3|a1|769|
1|4|a|1025|
1|5|a|1281|
1|1|b|1537|

As you can see we have 6 rows in the file. And only 5 on the table. We have a problem.
The row with primary key (1,1) is duplicated. How can this happen? In order to understand it, we need to understand how the queries are processed and that Informix is not a multi-version database (just like SQL Server, DB2 in most cases, Sybase and some others).
The sequence of events is:

1. We have a table with 5 rows. And we lock row number "3"
2. In parallel we start a full scan of the same table. We read rows 1 and 2 and we get stuck on row number 3
3. While we're still holding the lock we do another parallel operation where we remove row 1, and insert it again (with a different value for col3 for better understanding) on a different physical location
4. We unlock row 3
5. The full scan continues and reads row 1 again, on another physical location

If you're scared with this, don't be. This requires several factors to happen:

1. You must access the table with a full scan
2. You must DELETE a row that was already read, and INSERT the same row in a physical location yet to be read
3. You need to DELETE and INSERT rows with the same primary key or unique index values

And there are ways to avoid this:

1. Force an index scan
2. Use some query condition that will skip rows that are inserted after your query starts (usable if the table has some sort of timestamp condition)
3. Run the query in REPEATABLE READ isolation level
4. Use a new functionality in 12.1

Most of the ways to avoid this effect may not be usable. The index scan can cause a serious performance impact. The timestamp condition depends on the table schema. The REPEATABLE READ will cause a lot of locks if the table is big, and would stop all change activity on the table (for that we could use a LOCK TABLE test IN SHARE MODE)
So, how can 12.1 help us avoid this? Well it introduces the so called OLAP window functions, and one example is ROW_NUMBER(). You might recall I've written an article about ROWNUM and there I stated that to achieve somethings we would need to change the engine. And that the proposed UDR on that article would have to be customized to implement PARTITION BY clauses. Well, with 12.1 we can use the standard syntax and we could write the UNLOAD query like:

UNLOAD TO test.unl
SELECT * FROM
(
SELECT
t.*, ROWID, ROW_NUMBER() OVER (PARTITION BY col1,col2) AS rown
FROM test t
)
WHERE rown = 1;

This looks a bit more complex, but it's not hard to understand.
I'm introducing the ROW_NUMBER() function, that will add a sequential number to each row, but with one particularity: The number will restart (1) for each pair of col1, col2 which I specify in the PARTITION BY clause. The result set is this one:
1|1|a|257|1|
1|2|a|513|1|
1|3|a1|769|1|
1|4|a|1025|1|
1|5|a|1281|1|

As you can see the new insert row is not there. Why? Because I have a constraint that the ROW_NUMBER() must be equal to one. If we remove it we get:
1|1|a|257|1|
1|1|b|1537|2|
1|2|a|513|1|
1|3|a1|769|1|
1|4|a|1025|1|
1|5|a|1281|1|

Note that I used ROWID and the ROW_NUMBER() in the projection clause, but that was only for academic purposes. ROWID shows the physical location and the result of ROW_NUMBER() shows how it works and how I used it.

There are many other OLAP window aggregate functions. You can discover them here and check on the PARTITION BY, ORDER BY and other clauses that can be used together.

It's important to note that the functionality of "OLAP window aggregates" introduced new aggregate functions, but it also extended the use of some "old" functions like SUM(), COUNT(), AVG() etc. which now allow the use of the OVER clause.
From an informix user perspective this is a great step forward, because some of these functions allows us to write SQL statements to generate reports that otherwise would require some programming. This means not only that the usability is improved, but also that Informix can now handle queries sent by BI tools (like Cognos and others). This is very important from a supportability point of view. These functions are present in other databases for some years and this was really something that was missing. This is even more important because queries with these functions can still benefit from the presence of the Informix warehouse accelerator. Meaning the BI user can take advantage of better integration with the tools normally used in BI environments and also from the speed provided by IWA.



Versão Portuguesa:
 Neste artigo vou referir uma nova funcionalidade da versão 12.10, mas irei usar isso para responder a uma questão que apareceu recentemente na lista de correio do IIUG. A questão original referia-se a quando é que o Informix atualiza os índices durante uma transação. Mas após algumas trocas de impressões parecia claro qual era o problema e é um pouco complexo:
O utilizador estava a fazer um UNLOAD de uma tabela que continha um chave primária e apareciam registos duplicados (relativamente à chave primária) no resultado. Naturalmente isto parecia um bug, mas há uma explicação técnica para o fato. Vamos descrever um procedimento simples que permite reproduzir o problema. Para tal temos três simples scripts SQL que serão executados através do dbaccess:

#-------- main.sql
DROP TABLE IF EXISTS test;
CREATE TABLE test
(
        col1 INTEGER,
        col2 INTEGER,
        col3 CHAR(2000),
        PRIMARY KEY (col1,col2)
)
EXTENT SIZE 16 NEXT SIZE 16
LOCK MODE ROW;

INSERT INTO test VALUES ( 1, 1, 'a');
INSERT INTO test VALUES ( 1, 2, 'a');
INSERT INTO test VALUES ( 1, 3, 'a');
INSERT INTO test VALUES ( 1, 4, 'a');
INSERT INTO test VALUES ( 1, 5, 'a');

BEGIN WORK;
UPDATE TEST SET COL3 = 'a1' WHERE col1 = 1 AND col2 = 3;
!/bin/sleep 30
COMMIT WORK;


#-------- unload.sql
SET LOCK MODE TO WAIT;
UNLOAD TO test.unl
SELECT *, ROWID FROM test;

#-------- move_rows.sql
BEGIN WORK;
DELETE FROM test WHERE col1 = 1 AND col2 = 1;
INSERT INTO test VALUES (1, 1, 'b');
COMMIT WORK;

O primeiro script chama-se "main.sql" e cria uma tabela com lock ao registo e esta tabela tem uma particularidade que ajuda à reprodução: Cada página de dados contém apenas um registo. Como executei isto em Linux, onde o tamanho pré-definido das páginas é de 2KB, usei um tamanho de CHAR(2000). Se executar em AIX por exemplo, onde a página será de 4KB, deverá usar CHAR(4000). Depois de criar a tabela, o script carrega 5 registos. Note que estou a usar uma chave primária composta, mas usar uma chave primária simples ou mesmo um índice único seria o mesmo.
Depois inicio uma transação e altero a linha "3", executando depois um comando externo que força uma pausa de 30 segundos antes de fazer o COMMIT. Isto dá-nos tempo mais que suficiente para executar os outros scripts em paralelo.

O próximo script chama-se "unload.sql" e executa um simples UNLOAD da tabela, depois de alterar o LOCK MODE para WAIT. Como seria de esperar, nestas condições o script irá ficar em espera pelo primeiro que causa um lock na linha "3".

O último script tem a "magia". Efetua um DELETE a uma linha com uma determinada chave primária e depois volta a fazer o INSERT de uma linha com essa mesma chave, mas um valor diferente na coluna "col3" (apenas por uma questão de clareza)
Usarei o script SHELL seguinte para executar os scripts SQL que reproduzem o problema:

#!/bin/bash
dbaccess stores main.sql 1>main.out 2>&1 &
sleep 5
dbaccess stores unload.sql 1>unload.out 2>&1 &
sleep 5
dbaccess stores move_rows.sql 1>move_rows.out 2>&1 &
wait

Portanto... Lança o "main.sql" em background, depois adormece durante 5 segundos (para garantir que o "main.sql" chega à parte em que cria o lock no registo "3"). De seguida lança o "unload.sql" que irá ficar bloqueado ao chegar ao registo "3", sendo que este também é lançado em backgroud. Por fim executa o script que efectua o DELETE e o INSERT da linha com determinada chave primária (1,1) e espera pelo retorno dos três processos.
O resultado do ficheiro de unload é:
1|1|a|257|
1|2|a|513|
1|3|a1|769|
1|4|a|1025|
1|5|a|1281|
1|1|b|1537|

Como pode verificar temos 6 linhas no ficheiro. E apenas 5 na tabela. Temos um problema.
A linha com a chave primária (1,1) aparece duplicada. Como pode tal acontecer? Para entedermos isto temos de entender como é que as queries são processadas e também que o Informix não é o que se designa por base de dados multi-version (bem como SQL Server, DB2 na maioria dos casos, Sybase e várias outras).
A sequência de eventos é:

1. Temos uma tabela com 5 linhas e bloqueamos a linha "3"
2. Em paralelo iniciamos um varrimento completo da tabela. Lemos as linhas "1" e "2" e ficamos bloqueados na linha "3"
3. Enquanto ainda temos o lock, fazemos outra operação em paralelo onde se remove a linha 1 (já lida pelo varrimento) e inserimos novamente a mesma linha (com um valor diferente na coluna col3 para maior clareza) numa zona ainda não lida
4. Desbloqueamos a linha "3"
5. O varrimento continua e lê a linha 1 novamente, desta feita numa localização física diferente

Se isto o assusta, sossegue. São necessários vários fatores para que tal aconteça:

1. O acesso à tabela tem de ser feito por varrimento (full scan)
2. Tem de existir um DELETE a uma linha já lida, e um INSERT da mesma linha (em termos de chave primária), numa localização física que ainda vá ser acedida pelo varrimento
3. Tem de fazer o DELETE e INSERT de linhas com o mesmo valor da chave primária (ou de valores de índices únicos)

E existem formas de evitar isto:

1. Forçar o acesso por índice
2. Usar alguma condição na query que faça descartar linhas inseridas após o início da query (pode ser feito se a tabela contiver algum tipo de "carimbo" com o momento de inserção
3. Executar a query no modo de isolamento REPEATABLE READ
4. Usar uma nova funcionalidade da versão 12.1

A maioria das formas de evitar o problema podem não ser práticas. O acesso por índice pode ter impactos sérios na velocidade de execução da query. A condição adicional depende da estrutura da tabela e forma de inserção dos registos. O REPEATABLE READ irá causar imensos locks se a tabela for grande, e impediria toda a atividade de alteração sobre a tabela durante a execução da query. Aliás nessa situação seria melhor bloquear a tabela em modo SHARE)
Assim, como pode a versão 12.10 ajudar-nos a evitar isto? Bom, esta versão introduz o que se chamam de OLAP window functions. Um exemplo será a função ROW_NUMBER(). Poderá lembrar-se que escrevi um artigo sobre o tema, onde mencionei que para alcançar algumas funcionalidades seria necessário alterar código interno do motor. E que a proposta função (UDR) desse artigo necessitaria de ser adaptada a cada caso, se desejássemos implementar as cláusulas PARTITION BY. Bom, com a versão 12.10 temos acesso à sintaxe standard e podemos reescrever o UNLOAD da seguinte forma:

UNLOAD TO test.unl
SELECT * FROM
(
SELECT
t.*, ROWID, ROW_NUMBER() OVER (PARTITION BY col1,col2) AS rown
FROM test t
)
WHERE rown = 1;

Isto parece um pouco mais complexo, mas não é difícil de entender.
Apenas introduzi a função ROW_NUMBER() que irá adicionar um número sequencial a cada linha, mas com uma particularidade: O número será re-inicializado (1) para cada par das colunas col1, col2 tal como especifico com a cláusula PARTITION BY. O resultado será assim:
1|1|a|257|1|
1|2|a|513|1|
1|3|a1|769|1|
1|4|a|1025|1|
1|5|a|1281|1|

Como pode ver a nova linha inserida não aparece. Porquê? Porque a nova query tem uma condição que elimina registos onde o resultado do ROW_NUMBER() não seja 1. Se removermos esta condição passaremos a ter no resultado isto:
1|1|a|257|1|
1|1|b|1537|2|
1|2|a|513|1|
1|3|a1|769|1|
1|4|a|1025|1|
1|5|a|1281|1|

Convém referir que o uso do ROWID e ROW_NUMBER na lista de colunas da lista de projeção é meramente académico. O ROWID mostra a localização física da linha e o ROW_NUMBER serve para mostrar como funciona e como o usei.

Existem muitas outras funções OLAP window aggregates. Pode descobri-las aqui e verificar as cláusulas PARTITION BY, ORDER BY e outras que podem ser usadas em conjunto.

É importante notar que esta nova funcionalidade introduziu novas funções, mas também estendeu a utilização de algumas funções "antigas" como o SUM, COUNT(), AVG() etc. que agora permitem usar a cláusula OVER
Da perspetiva de um utilizador Informix, isto é um grande passo em frente, porque algumas destas funções permitem-nos escrever queries SQL para gerar relatórios que de outra forma necessitariam de algum tipo de programação. Isto significa que não apenas se melhorou a utilização, mas também que o Informix pode agora lidar com queries enviadas por ferramentas de BI (como Cognos e outras). Isto é muito importante do ponto de vista do suporte a aplicações. Estas funções já existem noutras bases de dados há vários anos e esta era realmente uma falha que foi agora colmatada.
Há ainda a registar que queries com estas funções podem mesmo assim beneficiar da presença do Informix Warehouse Accelerator (IWA). Quer isto dizer que o utilizador de BI pode aproveitar a melhor integração com as ferramentas normalmente usadas nesses ambientes e ao mesmo tempo aproveitar também a velocidade proporcionada pelo IWA.

Informix 12.10 is ready / Informix 12.10 está pronto

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



English version:
As we should all know by now, IBM announced the next major Informix version last Tuesday, March 26 with a webcast that is available for replay here.
I must confess I was a bit surprised with the webcast format. Being an IBMer, I was in touch with this new release and I knew most (if not all) the new features. And I was expecting a mostly technical session going through all the bits and bytes. Instead of that we got something that we're not used to in "informix land": A strategic positioning of the product and current direction with the focus on the main differentiation points. More importantly we got a partner going through their real world experience with the beta versions of the product, and some simple but effective graphics of the performance achievements.

I believe that from my own internal knowledge and from the webcast I can say that the main focus points of this release are (and I'm not going technical here/yet) with no particular order:

• TimeSeries data
  No other database has incorporated so much technology and effort for this. And while the classical usage examples are the smart meters, I believe we're still missing the point because there are so many "time series" sources out there (weather data, demographic data, smart cities data including traffic, people movement, noise data, air quality data etc..)
• Warehouse enhancements
  The Informix Warehouse Accelerator is really a unique product. Mix OLTP and BI use in the same system. Use in-memory technology. Allow for "self service" BI. Unprecedented low maintenance and ease of use. And this release brings the so called OLAP functions, or windowed aggregates, things like RANK(), LEAP(), ROWNUM() etc. These were lacking in Informix so it's the elimination of a gap
• Grid enhancements
  Again, I believe no other RDBMS has this capability as Informix provides. And the new grid queries open up a whole new world
• Usability
  The improvements in OAT. The SQL compatibility enhancements. More dynamic parameters. A datablade with many competitor functions for compatibility. The removal of some limitations in non-root installations and much more
• Changes in editions and bundling
  This point will always raise some discussion. In terms of names we went back to the workgroup and enterprise names, while there are other bundlesspecially for data warehouse environments which include some licenses for Cognos and SPSS. These ones have advanced in their names. Naturally there are technical and legal restrictions on their usage, so choosing between the several editions requires a careful analysis of their licensing terms

There is also another perspective to look at this release.... There are a few things that are a bit harder to understand about some of the new features... Things like temp structures column elimination, faster ANSI joins and others that are not even mentioned (just check out the new sysmaster.sql) reflect a lot of hard work in the background that it's not easily translated into "features".

I was also surprised with the release process. Unfortunately we're used to see the software on Passport Advantage or FixCentral, then wait for the InfoCenter, than the PDF manuals.... And all these take a few days until it eventually is all available. This time I was able to download the software before the webcast. The InfoCenter was up and running, and the PDFs containing the manuals were available individually, and the whole PDF pack took one or two days. Again this was a very good surprise. I just hope we can keep it for the upcoming fixpacks.

As for the technical bits and bytes, I will try to catch up on the post rates while I cover some of the new features. For now, if you're interested (and you should be), please check the "What's new" link in InfoCenter



Versão Portuguesa:

Como todos já devemos saber, a IBM anunciou a próxima versão do Informix na passada terça-feira, 26 de Março, num webcast que está disponível para rever aqui.
Tenho de confessar que fiquei um pouco surpreendido com o formato da apresentação. Sendo um IBMer, tinha já algum contacto com esta nova versão e conhecia a maioria (senão todas) das novas funcionalidades. E estava a aguardar uma sessão essencialmente técnica que explicasse todos os bits e bytes. Em vez disso observámos algo a que não estamos muito habituadas no "mundo informix": Um posicionamento estratégico do produto, com a visão e direção atual, e o foco nos principais pontos diferenciadores. Ainda mais importante, tivemos a presença de um parceiro que descreveu a sua experiência com situações reais usando as versões beta do produto, e alguns gráficos simples mas eficientes que demonstraram significativos ganhos de performance com esta versão.

Penso que juntando as mensagens internas e este webcast, se pode dizer que os principais pontos desta nova versão são (não vou abordar aspetos técnicos aqui/ainda), sem nenhuma ordem especial:

• Dados TimeSeries
  Nenhuma outra base de dados incorporou tanta tecnologia e esforço para isto. E se por enquanto o exemplo clássico são os contadores inteligentes (smart meters) penso que ainda estamos a falhar oportunidades, porque existem tantas fontes de dados timeseries por aí (dados de clima, dados demográficos, dados de smart cities incluindo medições de tráfego, movimentos de pessoas, medidas de ruído, qualidade do ar etc...)
• Melhorias para Warehouse
  O Informix Warehouse Accelerator é realmente um produto único. Misturar utilização OLTP e BI no mesmo ambiente. Uso de tecnologia in-memory. Baixa manutenção e facilidade de uso sem precedentes. Permitir BI self service. E esta versão traz as funções OLAP windowed aggregates, coisas como o RANK(), LEAP(), ROWNUM() etc. Estas faziam falta ao Informix há bastante tempo, pelo que se trata da eliminação de uma falta
• Melhoramentos em Grid
  Novamente, julgo que nenhuma outra base de dados relacional tem a capacidade demonstrada pelo Informix. E as novas grid queries abrem todo um novo mundo
• Facilidade de utilização
  As novas funcionalidades no OAT. A melhoria de compatibilidade de SQL. Mais parâmetros dinâmicos. Um datablade com várias funções compatíveis com a concorrência. A remoção de algumas limitações em instalações sem recurso a root
• Alteração nas edições
  Este aspeto será sempre polémico. Em termos de nomenclatura voltou-se ao workgroup e enterprise, havendo outras edições pensadas para data warehouse que incluem licenças para alguns utilizadores de Cognos e SPSS. Estas designam-se por advanced. Naturalmente algumas edições têm limitações legais e/ou técnicas ao seu uso, e a escolha de uma em vez de outra requer uma análise cuidada aos termos de licenciamento

Existe ainda outra perspetiva sobre esta nova versão.... Há algumas coisas que não são fáceis de compreender relativamente às novas funcionalidades.... Coisas como a eliminação de colunas em estruturas temporárias (como tabelas derivadas), joins ANSI mais rápidos, e outras que nem são mencionadas (verifique por exemplo o novo sysmaster.sql) refletem um significativo trabalho  de bastidores que nem sempre é fácil traduzir em novas funcionalidades

Fiquei também surpreendido com o processo de publicação e disponibilização de ficheiros e manuais. Infelizmente estamos habituados a ver o software no site Passport Advantage ou FixCentral, depois esperar pela atualização do InfoCenter, depois os manuais em formato PDF... E tudo isto demora alguns dias até estar realmente disponível. Desta vez consegui transferir o software, antes do inicio do webcast. O InfoCenter estava disponível e os PDFs dos manuais estavam disponíveis individualmente. O pacote completo de manuais demorou um ou dois dias a aparecer. Esta foi outra das boas surpresas deste lançamento. Espero que consigamos manter este procedimento para os futuros fixpaks

Quanto aos detalhes técnicos tentarei retomar um bom ritmo de artigos enquanto tento abordar algumas das novas funcionalidades. Por agora, se estiver interessado (e deverá estar) verifique o link "What's new" no InfoCenter

12.10 on the loose / 12.10 anda à solta

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

English version:

Just before today's webcast that will announce the next major Informix version (12.10) it was seen on the FixCentral site.
Start the download while you listen at the webcast. You'll have plenty of time to download it and install it while you learn what's new!

Versão Portuguesa:

A versão 12.10 já está disponível no site FixCentral, mesmo a tempo do webcast que irá anunciar a próxima major version.
Comece o download enquanto assiste ao webcast. Terá tempo suficiente para fazer a transferência e instalação enquanto ouve o que tem de novo.

Analytics: How fast do you think? / Analytics: Quão rápido consegue pensar?

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

English version:

I was educating myself on the Internet when I came across another IT jargon expression, or another buzzword. The IT industry is very prolific when it comes to creating buzzwords. And we the technical people usually look at those ideas with some distrust. But although this is used by the marketing teams to promote products, increase sales and create awareness and needs on the customers, they actually summarize perfectly concepts that are in some cases very complex. Take "SOA" (Service Oriented Architecture), BigData and so on as examples. Many people use them (and some even assume they need it) without really understanding them. But why am I going through this? Because I was hit by a new buzzword that I can really map to something I know and that really describes the power of that "thing" I know... Let's start by the buzzword first: "Analytics at the speed of thought". It has been used for years to describe products, concepts and technologies that try to provide exactly that: The ability to analyze data at the speed you think... But let's go back a little bit... What is "data analysis"? Well we can consider it a big umbrella, and depending on your background, fit things like reporting, market segmentation, CHURN, market basket analysis etc. But IT departments have been doing this and providing this to business users for a long time. Datawarehouses, datamarts and so on. Everybody has them. But as usual, that's not enough... We're constantly pushing the limits and trying to take advantage of latest technology improvements. And now we're getting to a point where we can "explore" the data that we have... The idea is not to have a report on our desk each morning that took part of the night to run... These reports can contain some very valuable business data that tells us how things are going... which customer are about to leave us etc. The idea is that we can, and should, use the data to explore new business ideas, to create virtual scenarios and in summary, to learn things that we never though about before. And that requires the ability to process data at our speed... and our speed is the speed of thought... I'm sure yours is not slower than mine, and I'd like to think mine is pretty quick (not always I must admit!). The big point is that if you have an idea, an hypotheses, and you need to verify if your business data confirms it, you don't want to wait large minutes or even hours for your query. By the time it returns you lost your focus, and the creativity is wasted. You need the system to answer you in a few seconds... 1 or 2 minutes... Not much more.
But is it possible? Well, yes! And the solution depends on your environment.
As you can imagine, and since this an Informix blog I think we have a solution. Critics will probably be thinking that the solution is BigData, not an "OLTP database" like Informix. Well... I wouldn't replace a true BigData system that crunches thousands of Terabytes (think about Google, YouTube etc.) of non-structured data with Informix... But let me ask you... How many of us work in those kind of environments? For the "common people" we need something that is simple, that works, that's fast and that doesn't require highly qualified engineers and true "data scientists".
And now, yes, I can tell you what I'm thinking about: Informix Warehouse Accelerator. I've mentioned it before, and I've published a reference to a video that explains the raw concepts much better than what I'll ever be able to do. But in short it:

• Is a new generation in-memory database
• Takes advantage and is completely adjusted to new chips technology
• Is designed to scale just by adding a new machine (or node)
• Is transparent to the regular applications and to any application that can use JDBC, ODBC etc.
• Is tightly coupled with your regular database that you can use for your OLTP needs
• It's amazingly fast (yes... Speed of Thought)... Allows the "think", click, look at the results, "rethink", click again, look at new results type of work
• It's unbelievable simple to setup and use
• Fit's your real size... it was made for you... Not for the "big boys" and then pushed down the marketing channels to the average business customers

The IBM Informix R&D understands that there is a real market need for a product with these characteristics. And as usual, they try their best to follow the right directions. I believe we can expect a great focus on this in the next major Informix version. If you want to find out more don't forget to attend the public webcast on March 26. I'm sure you'll not be disappointed. Details and registration are here: http://t.co/bpOIJiFnCJ


Versão Portuguesa:

Estava a educar-me na Internet quando me cruzei com mais uma expressão ou jargão de TI, ou usando o termo Inglês uma buzzword. A área de Tecnologias de Informação é muito prolífica no que toca a criar estes chavões ou expressões. E nós o pessoal técnico, costumamos olhar para elas com alguma desconfiança. Mas apesar de estes conceitos serem criados e usados pelas equipas de marketing para promover produtos, aumentar vendas e criar consciência e necessidades nos clientes, a verdade é que resumem de forma perfeita conceitos que são algumas vezes bastante complexos.
Veja-se os casos de "SOA" (Service Oriented Architecture), BigData etc. Muitas pessoas usam estes termos, e até assumem que necessitam das ideias, mesmo sem que as compreendam muitas vezes.
Mas porque é que estou a navegar nestes temas? Bom, porque fui "atingido" por um destes chavões, mas que consigo realmente mapear para algo que conheço e que efetivamente descreve plenamente o potencial dessa "coisa" que eu conheço... Mas comecemos primeiro pelo "chavão": "Analytics à velocidade do pensamento" (decidi não traduzir "analytics" por manifesta dificuldade e porque penso que o termo é suficientemente conhecido). Este chavão tem sido usado há anos para descrever produtos, conceitos e tecnologias que tentam providenciar exatamente isso: A capacidade de analisar dados à velocidade que pensamos sobre eles... Mas recuemos um pouco.... O que é a "análise de dados"? Podemos considerar que é um grande toldo, e dependendo do seu contexto, lá podemos encaixar coisas como elaboração de relatórios, segmentação de mercado, CHURN, análise de cestos de compras etc. Mas os departamentos de informática têm feito isto e fornecido estas capacidades aos departamentos de negócio desde há longo tempo. Datawarehouses, Datamarts etc. Toda a gente os tem, toda a gente os usa. Mas como é hábito, isso tende a não ser suficiente. Estamos constantemente a tentar ultrapassar os limites e a tentar tirar mais proveito dos últimos avanços na tecnologia e do natural aumento de capacidade dos sistemas. E agora estamos num ponto em que podemos "explorar" os dados que temos... A ideia não é ter um relatório na nossa secretária de manhã que terá levado parte da noite a ser gerado... Estes relatórios podem conter alguma informação preciosa que nos diz como as coisas estão a correr... que clientes estão em risco de nos deixar etc... Mas a ideia é que podemos, e devemos, usar os dados para explorar novas ideias sobre o negócio, criar cenários virtuais, em suma aprender coisas que não sabíamos. E isso requer a capacidade de processar os dados à nossa velocidade.. e a nossa velocidade é a velocidade do pensamento. Aposto que a sua não é inferior à minha, e gosto de pensar que a minha é bastante rápida (tenho de admitir que nem sempre!).  O facto é que se temos uma ideia, uma hipótese, e se precisamos de confirmar se os nossos dados de negócio a verificam, não queremos nem podemos esperar longos minutos ou mesmo horas pelo resultado de uma query. Quando chegasse o resultado o nosso foco ter-se-ia perdido e a nossa criatividade teria sido desperdiçada. Precisamos que os sistemas respondam em alguns segundos... 1 ou 2 minutos... Não muito mais que isso.
Mas tal será possível? Sim! E a solução depende do seu ambiente.
Como é fácil de imaginar, e porque isto é um blog dedicado a Informix, julgo que temos uma solução. Os críticos irão desde já pensar que a solução é BigData, não uma "base de dados OLTP" como o Informix. Bom... Eu não trocaria um verdadeiro sistema BigData que "mastigue" milhares de Terabytes de informação não estruturada (pensemos no Google, YouTube etc.) por Informix... Mas deixe-me perguntar... Quantos de nós trabalhamos nesse tipo de ambientes? Para os "comuns mortais" precisamos de algo que seja simples, que funcione, que seja rápido e que não necessite de um exército de engenheiros altamente qualificados e verdadeiros data scientists.
E agora sim, posso revelar aquilo em que estou a pensar: Informix Warehouse Accelerator. Já o mencionei antes, e já publiquei uma referência a um vídeo que o pode explicar melhor do que alguma vez serei capaz. Mas em resumo:

• É uma base de dados in-memory de última geração
• Aproveita e está completamente ajustado à tecnologia dos últimos CPUs
• Está desenhado para crescer pela simples adição de mais máquinas (ou nós)
• É transparente para as aplicações habituais e para qualquer aplicação que "fale" JDBC ou ODBC
• Está intimamente ligado com a base de dados "normal" que pode usar para OLTP
• É espantosamente rápido (sim... velocidade do pensamento)... Permite o ciclo "pense", click, veja os resultados, "repense", click novamente e veja os novos resultados
• É inacreditavelmente fácil de instalar  e usar
• Ajusta-se ao tamanho real do seu negócio. Foi feito para si. Não é algo criado para os "gigantes" que depois foi empurrado para baixo pelos canais de marketing até chegar ao negócio médio

O departamento de I&D da IBM Informix compreende que existe uma necessidade real no mercado para um produto com estas características. E como é hábito tentam seguir a direção correta. Penso que podemos esperar um foco significativo nesta área na próxima versão do Informix. Se desejar saber mais sobre o tema não se esqueça de assistir ao webcast público no dia 26 de Março. Estou convencido que não sairá desapontado. Os detalhes e registo estão em: http://t.co/bpOIJiFnCJ

Audit for all... / Audit para todos...

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

English version:

In a recent post on the IIUG mailing list, a customer asked if it was possible to configure the audit facility on secondary servers (HDR, RSS and SDS). The author mentioned that by definition those servers were read only... Well, although that's not necessarily true since 11.50, the question does make sense because in earlier versions it was not possible. Thankfully, an IBMer promptly replied that "yes, if you're on 11.50". And it's true... but to be more precise, you need to be at least on 11.50.xC6.

The interesting aspect about this, is that in fact the functionality was introduced in 11.50.xC6, but it was not mentioned in the release notes. And the 11.50 manual was not completely updated and still mentions that it's not possible. The v11.70 manual was corrected in the onaudit utility section, but still mentions it's not supported in another section (PMR opened for documentation fixing).

So, bottom line, regardless of the documentation issues and lack of information, is that we can audit on secondary servers. The only restriction is that the audit masks are defined only on the primary server. I believe it would be nice to have audit masks for each server role, but I don't think this is a major limitation.


Versão Portuguesa:

Numa mensagem recente na lista de correio do IIUG, um cliente perguntou se era possível configurar o sistema de audit nos servidores secundários (HDR, RSS e SDS). O autor mencionava que por definição esses servidores estão em modo de leitura apenas... Bem, apesar de isso não ser necessariamente verdade desde a v11.50, a questão faz sentido porque em versões antigas isso não era possível. Felizmente um IBMer respondeu rapidamente, dizendo "sim se estiver na v11.50". E é verdade... embora para ser mais preciso, se tenha de estar pelo menos na v11.50.xC6.

O aspeto interessante disto, é que de facto a funcionalidade foi introduzida na v11.50.xC6, mas não foi mencionada nas notas (release notes) dessa versão. E o manual da v11.50 não foi completamente atualizado e ainda menciona que não é possível. O manual da v11.70 foi corrigido na secção sobre o utilitário onaudit, mas ainda mantém que não é suportado noutra secção (PMR para correção da documentação já foi aberto).

Assim, em resumo, independentemente de todos os problemas na documentação e a falta de informação, a verdade é que se pode utilizar o audit nos servidores secundários. A única restrição é que as máscaras de audit têm de ser definidas no servidor primário e aplicam-se a todos os servidores onde se ligue o audit. Acredito que seria bom ter máscaras de audit para cada estado do servidor, mas não me parece que seja uma limitação muito séria