Informix version 15 is GA

Informix version 15 is GA! (original version here)

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

• Java: Engine does not include a JRE environment. And Java version 11 is needed (Informix HQ and Java UDRs for example)
  
  
• GSKit updated to version 8.0.60.1
  
  
• The "real thing": The internal limits were changed. This means that a lot of limits that we're used to are now much higher. So high that it looks like there is no limits. I'd say none of us will have to worry about limits during our career. But we've seen many examples in the past where people assured similar things and then it turned out as big failed previsions. Let me quote the new limits from the fine manual:
• A single table fragment/partition can have 140 trillion pages
• A chunk may be as large as 8 exabytes (this is the unit after Petabyte which is above Terabyte. So an exabyte would be 1024x1024 Terabytes. Yes.... a very large number)
  
• Data rows per page depends on pagesize but can reach 29122 in 256KB pages (maximum was 255 independently of page size)
  
• Page size can be 2, 4 ,8, 16, 32, 64, 128 and 256 KBytess (maximum was 32)
• Data rows per fragment/partition is 9.2 quintillion 

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

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

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

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

• Improved audit records analysis. This means the Session ID (SID) can appear in the audit logs. Since I mentioned images, let me show another one:
  
  Yes... I opened this feature 9 years ago. And before that I had many internal discussions to try to push this. The argument was simple: The information is nearly useless without this because just by using the client process ID means that in many cases we cannot correlate the actions shown in the log. The argument against was always the dreadful "we cannot make the outputs incompatible with previous behavior". Check!
  

• Replication update: changes to '--cascade replicate'. The --cascade replicate option is now generally available for replicates, also through templates. A replicate having the --cascaderepl option turned on will be able, on its only sending participant, to pick up transaction traffic arriving through other replicates. This used to be available only for SPL replication situations
  
  
• Informix HQ 3.0
• Automatic account lockout after 5 invalid access attempts
• Support for "LARGE TABLES". We can create LARGE TABLEs and see if a table is categorized as SMALL or LARGE table. A future article will dive into what is a LARGE table. For now let's just assume it's a table with expanded capacity
• Droping constraints directly from the user interface
• Multiple servers refresh simultaneously
  
  
• CDC API support on secondary servers. I've been using InfoSphere Change Data Capture (InfoSphere CDC) very much lately, which uses the Informix CDC API. Being able to take advantage of secondary servers will be great news for Informix customers who use CDC to send data to other systems.
  
  
• New version format. Not exactly a new functionality, but something we all need to get used to. Traditionally Informix versions had the format M.R.xyz.Extra where:
• M.R was the major release (11.50, 11.70, 12.10, 14.10)
• x was the platform indication (F for 64 bit, U for 32 bit and T for Windows)
• y was the type of release (B for Beta, C for initial release, D for later release with significant changes)
• z was the fixpack number
• Extra was a mark for specific fixes like "X1"
  

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

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

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

Heads up!

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

 

 

 

Versão Portuguesa 

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

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

• Java: O motor deixa de incluir um JRE. E a versão Java necessária é a 11 (Informix HQ e Java UDRs por exemplo)
  
  
• GSKit actualizado para a versão 8.0.60.1
  
  
• A grande mudança: Os limites internos foram mudados. Isto significa que muitos dos limites a que nos habituámos estão agora muito maiores. Tão maiores que dão a sensação que deixou de haver limites. Diria que nenhum de nós terá de se preocupar com limites durante a nossa carreira. Mas já vimos muitas personalidades ilustres fazerem este tipo de afirmação e depois revela-se que foram apenas previsões falhadas. Deixem-me citar alguns limites a partir do manual:
• Um único fragmento/partição de uma tabela pode ter 140 triliões de páginas
• Um chink pode atingir 8 exabytes (isto é a unidade acima do Petabyte que está acima do Terabyte. Portanto um exabyte serão 1024x1024 Terabytes. Sim.... um número muito grande)
  
• Número de linhas por página depende do tamanho da página mas pode chegar às 29122 em páginas de 256KB (o máximo era 255 independentemente do tamanho da página)
  
• Os tamanhos de página podem ser 2, 4 ,8, 16, 32, 64, 128 e 256 KBytess (o máximo era 32)
• Linhas por fragmento/partição é de 9.2 quintiliões
  

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

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

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

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

• Melhoria na análise dos registos de auditing. Isto significa que a identificação da sessão pode aparecer nos logs de auditing. Já que falamos de imagens deixem-me partilhar mais uma:
  
  Sim.... Abri esta funcionalidade há 9 anos atrás. E antes disso tive várias discussões internas para tentar promover isto. O argumento era simples: A informação guardada (sem ID de sessão) era virtualmente inútil, pois usando apenas o ID do processo cliente não permitia correlacionar as operações auditadas. O contra-argumento era sempre o drástico "não podemos mudar os outputs para formatos incompatíveis com versões anteriores". Check!
  

• Alterações na replicação: mudanças na opção '--cascade replicate'. Esta opção está agora genericamente disponível para replicates, e também através de templates. Um replicate com esta opção activada, poderá, no seu único participante marcado como sender, replicar dados que cheguem de outros replicates. Isto só estava disponível para replicação por SPL
  
  
• Informix HQ 3.0
• Bloqueio automático de contas ao fim de 5 tentativas de acesso falhadas
• Suporte para "LARGE TABLES". Podemos criar LARGE TABLEs e ver se uma tabela está caracterizada como SMALL ou LARGE. Um próximo artigo aprodunará o tema das LARGE TABLEs. Por agora vamos apenas assumir que uma LARGE TABLE é uma tabela com capacidade expandida
• Eliminar constraints directamente pelo GUI
• Refrescamento de vários servidores em simultâneo
  
  
• Suporte à API de CDC API nos servidores secundários.Tenho usado o InfoSphere Change Data Capture (InfoSphere CDC) muito ultimamente, um produto que usa a  Informix CDC API. Poder tirar proveito dos servidores secundários para este fim é uma excelente notícia para os clientes Informix que usam o CDC para enviar dados para outros sistemas.
  
  
• Novo formato da versão. Não é exactamente uma nova funcionalidade, mas sim algo a que teremos de nos habituar. Tradicionalmente o Informix usava o formato M.R.xyz.Extra onde:
• M.R era a major release (11.50, 11.70, 12.10, 14.10)
• x era o indicativo de plataforma (F para 64 bits, U para 32 bits e T para Windows)
• y era o tipo da release (B para Beta, C para release inicial, D para releases posteriores com mudanças significativas)
• z era o número do fixpack
  
• Extra era a marca para fixes específicos como "X1"
  

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

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

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

Aviso!

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