Informix 12.10.xC3

This article is written in English and Portuguese (original version here)
Este artigo está escrito em Inglês e Português (versão original aqui)

English version:

IBM has just released Informix 12.10.xC3 this last Friday (March 14). The packages were available on FixCentral since the beginning of the week, but the documentation was updated only on Friday. As usual for a few years each fixpack contains small improvements and a few gems. This one is no exception. Here is the list directly from the documentation with a few comments added:

• Migration
• Server changes
• JSON compatibility pre- and post-migration requirements
• New reversion requirements
  These are "just" some new parameters and things we should consider when upgrading or downgrading. I will refer to some of them later
• Installation
• Server configuration
• Automatically configure the server during installation
  If we choose to configure a server during installation, resources are adjusted automatically and the JSON listener is started
• Administration
• Autonomics
• Automatic resource tuning for performance
  Some of the new parameters mentioned above are relevant to this. As an example we can have a dynamic buffer pool, let the server create more logical logs, let it adjust the physical log size and reconfigure the CPU and AIO VPs. This is another great step in the autonomic chapter.
• Automatic location and fragmentation
  Another major change. If you prefer (set AUTOLOCATE parameter) the new tables are automatically created in a set of dbspaces, and fragmented in round-robin. If the tables grow, new fragments are automatically created. No more "no more pages" errors. For the old timer DBA (like me) this sounds tricky... but times do change and we must keep up. You're not forced to use this, but it will probably fit some environments
• Performance
• Control the size of private memory caches
  In previous fixpacks the private memory caches used by each CPU VP changed to dynamic. Now you have the option to make them static
• Virtual shared memory segment size doubling
  Like we do in the extents for the tables, each 16 memory segments that we allocate we double their size. The idea is to keep their number low. But again, for old timers, 16 is already a very large number. We usually try to keep them below 5 (?). But this also means we can have them lower initially because we know that if the server grows to much, it will adapt.
• Connectivity
• Retrying connections
  As we've seen in 11.70.xC8, we can now define INFORMIXCONTIME and INFORMIXCONRETRY as $ONCONFIG parameters and by using the SET ENVIRONMENT statement.
  This seems nice but to be honest I was not really getting it (I should have noticed it when I wrote about 11.70.xC8). My confusion is caused by the fact that I usually use these settings to avoid spending too much time trying to connect to a dead or unreachable server. But if we cannot reach the server how would having these settings on the server side help?!
  Because this is to be applied on distributed queries and for that it makes sense.
• Application development
• JSON compatibility
• Use the MongoDB API to access relational data
  You can access relational tables with the MongoDB API methods
• Improved JSON compatibility
  New MongoDB API methods are supported like findAndModify() and some authentication related operations
• Foreign-key constraints
• Temporarily prevent constraint validation
  As in 11.70.xC8 this introduces the ability to use NOVALIDATE on foreign-key constraints creation to speed up the process
• Faster creation of foreign-key constraints
  As in 11.70.xC8, real creation of foreign keys can take better advantage of existing indexes
• Compatibility
• Find the quarter of the calendar year for dates
  Implementation of the QUARTER() SQL function. A request from the market for better integration with 3rd party BI tools
• High-availability clusters and Enterprise Replication
• Connection Manager
• Improvements to Connection Manager
  Introduction of two new redirection policies: ROUNDROBIN and SECAPPLYBACKLOG
• Monitoring
• View log-staging information on RS secondary servers
  Get information about log staging information in RSS servers where the DELAY APPLY functionality is in use
• Configuration
• Easier configuration and cloning of a server for replication
  Easily configure and start Enterprise Replication
• Sharding
• Shard data across Enterprise Replication servers
  Shard is a term that refers to the distribution of a single object across a number of nodes. The purpose is a bit like "divide and conqueror". By distributing records, documents or rows we make them more manageable in each node and gain performance by having more hardware dealing with our data. Informix can now "shard" relational tables and collections (JSON) across instances in an Enterprise Replication domain
• Spatial data
• Enhancements for handling spatial data
  More spatial reference systems and the ability to calculate area and distance for data based on the round-Earth model.
  Informix spatial data types now conform to the OpenGIS Simple Features Specification for SQL Revision 1.1 and the ISO/IEC 13249-3 SQL/MM Part 3: Spatial. The Informix spatial solution is based on the ESRI SDE 10.2 Shape and PE libraries.
• Time series data
• Storage
• Efficient storage for hertz and numeric time series data
  Timeseries can store a series of sub-second values in a packed element (up to 4KB)
• Containers
• Control the destroy behavior for rolling window containers
  Limit the number of windows of a rolling window container that can be destroyed in a single operation
• Monitor groups of containers with wildcard characters
  Several monitorization functions now allow wildcards in the container name
• Faster queries
• Faster queries by running time series routines in parallel
  Functions that can be used in WHERE clause of a SELECT statement now can take advantage of PDQ PRIORITY (parallelism) if the tables are fragmented
• Faster queries with IN conditions through virtual tables
  Optimization for queries with IN conditions
• Warehousing
• Additional types of data
• Accelerate warehouse queries in-memory using data from multiple sources
  Synonyms and views can  now reference tables in different databases, tables in databases of the same Informix instance, or tables in a different Informix instance. This work for JSON data also

Beyond the very light review above, I'd like to highlight a few points:

1. Dynamic buffer pool. Although currently it can "only" be set to self tune (it will grow within specified limits if the read cache hits are lower than a threshold we define), this will be an historical step. I remember that while explaining the dynamic parameters we were introducing, I sometimes mentioned that "some like BUFFERPOOL will possibly never be dynamic".... Well, I must rethink that statement. Although currently it's not dynamic, if it can automatically adjust the buffers, I imagine we'll be able to do the same in the future (by using onmode -wm/wf for example)
2. You may noticed that some features introduced in xC3 of version 12.10 were already introduced in xC8 of version 11.70. This happens because some features are being developed across more than one code line, and they appear first in version N-1 or N depending on the release schedule and calendar. Nothing to do with marketing... If the code change is feasible in more than one version we give it to customers. We don't force them to upgrade to get any new stuff. How many vendors incorporate new features in previous product versions?!
3.  Continuous improvements in many distinctive areas: Timeseries, JSON, IWA.

Versão Portuguesa:

A IBM acabou de lançar o fixpack 12.10.xC3 esta última sexta-feira (14 de Março). Os pacotes estavam disponíveis no FixCentral desde o inicio da semana, mas a documentação só foi atualizada na sexta-feira. Como é habitual desde há uns anos, cada fixpack contém algumas pequenas melhorias e algumas pérolas. Este não é exceção. Aqui está a lista diretamente da documentação com alguns comentários adicionados:

• Migração
• Mudanças no servidor
• Compatibilidade com JSON: requisitos pré e pós-migração
• Novos requisitos para regressões
  Existem alguns novos parâmetros e algumas ações a ter em conta quando se efetua um upgrade ou downgrade de versão. Irei mencionar alguns mais tarde
• Instalação
• Configuração do servidor
• Configuração automática do servidor durante a instalação
  Se escolhermos configurar um servidor durante a instalação, os recursos são ajustados automaticamente e o serviço de JSON é iniciado
• Administração
• Autonomics
• Ajuste de recursos automático para melhorar o desempenho
  Alguns dos parâmetros mencionados acima são relevantes para isto. Como exemplo podemos ter uma área de buffers dinâmica, deixar o servidor criar mais logical logs, alterar o physical log e reconfigurar os VPs do tipo CPU e AIO. È mais um passo significativo no capítulo da auto-gestão dos servidores
• Fragmentação e alocação automática
  Mais uma mudança significativa. Se preferirmos (definindo o parâmetro AUTOLOCATE) as novas tabelas são espalhadas automaticamente por um conjunto de dbspaces e fragmentadas por round-robin. Se as tabelas crescerem, novos fragmentos serão automaticamente criados. Acabam-se os erros "no more pages". Para os DBAs "antigos" (como eu) isto parece suspeito... Mas os tempos mudam e temos de os acompanhar. Não somos obrigados a usar isto, mas sem dúvida que se ajusta a alguns ambientes.
• Desempenho
• Controlo sobre o tamanho das caches privadas
  Em fixpacks anteriores a memória privada alocada às caches de cada CPU VP passou a ser dinâmica. Agora existe a possibilidade de escolha e podemos defini-las com um tamanho estático também
• Duplicação do tamanho dos segmentos virtuais
  Tal como fazemos nos extents das tabelas, a cada 16 segmentos que alocarmos o seu tamanho duplica. A ideia é manter o seu número "baixo". Mas mais uma vez, para os "antigos", 16 já é um valor demasiado alto. Normalmente tentamos manter o seu número abaixo de 5 (?). Mas apesar disso, isto significa que talvez possamos definir o seu tamanho muito mais pequeno ao início, pois sabemos que se o servidor crescer muito irá adaptar-se
• Conectividade
• Definição de tentativas de conexão
  Como vimos na 11.70.xC8, podemos agora definir as variáveis INFORMIXCONTIME e INFORMIXCONRETRY como parâmetros no $ONCONFIG e pela utilização da instrução SET ENVIRONMENT.
  Isto parece muito bem, mas para ser honesto, receio que não estava a compreender totalmente esta funcionalidade (e devia ter notado isto quando escrevi sobre a 11.70.xC8). A minha confusão foi causada pelo fato de que habitualmente uso estes parâmetros ou variáveis para evitar perder muito tempo a tentar ligações a um servidor que está em baixo ou não está acessível. Mas nesses casos, como é que ter estes parâmetros do lado do servidor ou numa sessão já estabelecida ajudariam?! Na verdade a ideia é aplicar isto a queries distribuídas e aí já faz todo o sentido
• Desenvolvimento aplicacional
• Compatibilidade com JSON
• Usar a MongoDB API para aceder a dados relacionais
  Podemos aceder a tabelas relacionais (tradicionais) do Informix com os métodos da MongoDB API
• Mais compatibilidade com  JSON
  Mais métodos da MongoDB API são agora suportados como o findAndModify() e alguns outros relacionados com autenticação
• Chaves estrangeiras
• Desabilitar temporariamente a validação das chaves estrangeiras
  Como na 11.70.xC8, isto introduz a possibilidade de usar a cláusula NOVALIDATE na criação de chaves estrangeiras
• Criação mais rápida de chaves estrangeiras
  Tal como na 11.70.xC8, a criação de chaves estrangeiras (com validação) pode tirar mais proveito de índices já existentes
• Compatibilidade
• Obter o trimestre (quarter) de uma data
  Implementação da função SQL QUARTER(). Um pedido do mercado para integração com terceiros, fornecedores de ferramentas de BI
• Clusters de alta-disponibilidade e Enterprise Replication
• Connection Manager
• Melhorias no Connection Manager
  Introdução de duas novas políticas de redirecionamento: ROUNDROBIN e SECAPPLUBACKLOG
• Monitorização
• Obter informação sobre log staging em servidores secundários remotos
  Em servidores onde o DELAY APPLY foi ativado é possível agora obter informação sobre os logs que vão sendo acumulados
• Configuração
• Facilidade na configuração de um servidor para Enterprise Replication
  A ferramenta de clonagem (ifxclone) facilita agora a ativação automática de Enterprise Replication
• Sharding
• Shard de dados entre servidores configurados em Enterprise Replication
  "Shard" é um termo que se refere à distribuição de um objeto pelos nós de um cluster de replicação. O objetivo é um pouco "dividir para reinar". Ao distribuir registos, documentos ou linhas torna-mo-los mais manejáveis em cada nó e ganhamos desempenho pois temos mais hardware para os gerir. O Informix pode agora fazer o shard de tabelas relacionais e collections JSON entre instâncias configuradas num domínio de Enterprise Replication
• Dados espaciais
• Melhorias no tratamento de dados espaciais
  Mais sistemas de referência e a possibilidade de calcular áreas e distâncias em dados baseados no modelo esférico da Terra.
  Os tipos de dados espaciais seguem agora a norma OpenGIS Simple Features Specification for SQL Revision 1.1 e a ISO/IEC 13249-3 SQL/MM Part 3: Spatial. A solução espacial Informix é baseada nas bibliotecas ESRI SDE 10.2 Shape e PE
• Dados Timeseries
• Armazenamento
• Armazenamento eficiente para dados em séries numéricas e hertzianos
  Um elemento Timeseries compactado pode conter até 4KB de dados hertzianos (intervalos sub-segundo)
• Containers
• Controlo sobre o comportamento destrutivo de rolling window containersPodemos limitar o número de janelas que são destruídas numa só operação sobre um container em rolling window 
• Monitorizar containers com caracteres wildcard
  Várias funções de monitorização passam a aceitar wildcards nos nomes dos Containers
• Queries mais rápidas
• Queries mais rápidas via execução paralela de rotinas
  As funções que podem ser usadas na cláusula WHERE das instruções SELECT podem ser executadas em paralelo (tirando proveito dos valores de PDQPRIORITY) se as tabelas estiverem fragmentadas
• Queries mais rápidas nas condições IN sobre tabelas virtuais (VTI)
  Otimização de queries com IN
• Warehousing
• Tipos de dados adicionais
• Aceleração de warehouse queries in-memory usando dados de múltiplas fontes
  Sinónimos e views usados para o IWA podem agora referencias tabelas em diferentes bases de dados, tabelas da mesma instância ou tabelas noutras instâncias. Dados JSON podem também ser usados

Para além da breve análise acima, gostaria de salientar alguns pontos:

1. Buffer pool dinâmica. Apesar de atualmente "apenas" poder ser configurada para se auto-ajustar (crescerá se a percentagem de hits da cache de leitura ficar abaixo do limite por nós definido durante um intervalo de tempo), este será um passo histórico.
   Recordo-me de em várias ocasiões estar a explicar a transformação gradual dos parâmetros em dinâmicos (poderem ser mudados sem parar a instância), ter referido que "a BUFFERPOOL por exemplo possivelmente nunca será dinâmico". Parece que tenho de rever esta posição, ainda que de momento e no sentido estrito não o seja. Mas parece-me razoável pensar que no futuro poderemos mudar este parâmetro com um onmode -wm/-wf ou usando a SQL Admin API
2. Poderá ter reparado que algumas das funcionalidades aqui descritas já tinham aparecido na 11.70.xC8. Isto acontece porque algumas mudanças de código podem ser transversais às versões, aparecendo na N-1 ou N conforme o ciclo normal de releases e o calendário. Nada que ver com marketing. Se a mudança de código é viável na versão N-1 nós fornece-mo-la aos clientes. Não obrigados a estar sempre na última versão se quiser beneficiar de algumas inovações. Quantos fornecedores incorporam funcionalidades novas em versões anteriores dos seus produtos?
3. Melhorias contínuas em áreas que distinguem o Informix da concorrência: Timeseries, JSON e IWA.