Version 12.10.xC4 is out! / Saíu a versão 12.10.xC4

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


English version

I'm lagging behind on my objective of a post per week, but as usual... work... But I couldn't let this opportunity pass by. The latest Informix fixpack is out, and the online documentation was updated and the new PDFs are also available. Everything at once as it should be. Apparently this is becoming an habit, and although this would be expected, it didn't always happen, so I must say I'm happy it's happening now.
I'll repeat myself, but being true, I don't see why I shouldn't say it again: Once more we have a fixpack full of features. I honestly think the majority of our customers don't realize the changes the product have been going through... By changes I mean new features, as the "old" ones are still around. But on every fixpack it seems the possible usages and potential users are getting larger and larger. IBM is extending Informix to completely new areas, and I dare to say no other "traditional" RDBMS has seen such a transformation, or better saying adaptation to new requirements and new realities as Informix. As usual I'll pick up the official new feature list and I'll add my comments:

• Migration
• Server changes * Enterprise Replication conversion and reversion requirements * JSON compatibility conversion and reversion requirements
  Just a few notes you should consider when doing upgrades/downgrades
• Easier to import tables with large rows
  A feature that tries to avoid getting too large extents while importing tables with large LVARCHAR columns. With the new option "-D" the extents will be 16KB. If I was asked I'd say I would prefer to let the user to specify the value... Although I understand the issue, 16KB may be too little...
• Installation
• Easier installation of 32-bit programs on Windows 64-bit operating systems
  No more need to alter the PATH before installing a 32 bit program in 64 bit Windows
• Uninstall Informix programs on Windows from the Control Panel
  More convenient
• Administration
• Multitenancy in Informix
  Ok... this one deserves a post by itself. You may notice that one of our competitors created a large fuss around something very similar, and that was the big feature of a major release. We introduce it in a discrete fixpack. This fits perfectly in the overall picture of Informix vs other RDBMS. Basically we're build upon the concept of database inside an instance, something we've always supported (as well as in DB2 for that matter). In this fixpack we can now specify a class of CPU VPs and associate it with a "tenant" (CPU resource control), define the number of locks per session on that database, and associate a set of regular and temporary dbspaces for it. No objects from other databases will be allowed on that set of dbspaces, and that database objects can't be created outside of those dbspaces. Temporary dbspaces can however be used by different tenant sessions.
  If you think about it, this looks a simple extension to the database concept. But if you think a bit further you can easily find more things you'd like to do with these new tenants... Some can be "emulated" (I'm thinking about sessions per tenant). Others no, but I'd bet money on the idea that this will be continuously extended in the future
• Enhancements to OAT
  As usual, new engine features force new functionalists in OAT. Tenant management, in place alter elimination (provided through a task) and a few more
• Easier removal of outstanding in-place alter operations
  A new SQL Admin API function to eliminate existing in-place alters. This may help avoid more work during the DML operations on tables with these alters. As mentioned before OAT can be used to configure this
• Limit the size of extendable storage spaces
  Set up a limit for auto expansion of dbspaces/chunks. Useful in any case, but particularly needed for tenants
• Limit the number of locks for a session
  Finally this undocumented feature becomes officially. Can be set through $ONCONFIG or SET ENVIRONMENT....
• New default mode for the VP_MEMORY_CACHE_KB configuration parameter
  This parameter specifies the amount of memory cache each CPU VP can use. It was recently extended to have a second option (STATIC, DYNAMIC) do define if it would automatically grow. Now the default changed from DYNAMIC to STATIC
• Replication
• Enhancements to the Enterprise Replication apply process and memory pool allocation
  A new CDR_MEM parameter controls the way memory for enterprise replication is allocated. Two new methods are provided for a trade off between memory consumption and performance
• Replicate hertz and compressed time series data
  ER now allows the replication of both hert (sub-second frequency) and compressed Time Series data. This means these can be used in ER and GRID environments
• New event alarm for blocked replication transactions
  A new event alarm can now be triggered if transactions are being blocked because a table is in ALTER mode
• Performance
• Faster storage optimization
  The compress, uncompress, and repack operations can now be done in parallel by using that option in the commands. It's allowed both for tables and indexes
• Faster queries with UNION ALL views
  An optimization that tries to avoid the materialization of these type of views. Naturally without materialization, the queries can bu (much) faster
• Application development
• Customize the display widths of Unicode private-use characters
  Hopefully most of us won't have to deal with this, but for people using Unicode Private Use Area (PUA), the character base tools now allow the user to specify the display length of each character in that area. In order to do that a user needs to set IFX_PUA_DISPLAY_MAPPING environment variable and create a mapping file in $INFORMIXDIR/gls/etc/pua.map, specifying each character length (1 or 2, 1 being the default)
• SQL compatibility: LIMIT clause allowed after the Projection clause
  A simple SQL compatibility feature. We could already specify the maximum number of rows in a result set by using the LIMIT option in the projection clause:
  SELECT LIMIT 2 * FROM systables ORDER BY 1
  Now we can specify LIMIT as a clause:
  SELECT * FROM systables ORDER BY 1 LIMIT 2
• JSON compatibility
• Enhanced JSON compatibility
  As we've seen in previous fixpacks, the JSON functionality is an hot topic. Some of the features included in this fixpack are:
  
• Cursor support so that you can query large volumes of data
• Text search of string content in collections and tables
• Geospatial indexes and queries
• Pipeline aggregation operators
• The array update modifiers: $each, $slice, $sort
•  Import and export data directly with the wire listener by using the Informix JSON commands exportCollection and importCollection.
• Configure a strategy for calculating the size of your database by using the Informix extension to the MongoDB listDatabases command: sizeStrategy option or command.listDatabases.sizeStrategy property. 
• Customize the behavior of the wire listener by setting new properties. For example:
• logging,
• caching
• timeout
• memory pools
• maximum size of documents.
• Access Informix from REST API clients
  The JSON wire listner can be configured to answer REST API requests. These will use the MongoDB syntax and return JSON documents, but can access MongoDB collections, traditional tables and time series data.
  This makes it easy to interact with the database without installing drivers, just by using these methods.
• Create a time series with the REST API for the MongoDB API
  The REST API can be used to create a time series. Before you'd have to create it using standard SQL.
• Basic text searching support for JSON and BSON data
  Basic Text Search datablade was extend to allow indexes over JSON/BSON datatypes. The index can be created and used both through SQL and MongoDB API. BTS supports specific options for JSON documents as it did before for XML for example
• Access BSON data from JDBC client applications
  The JDBC driver now provides a JSON  object class called IfxBSONObject
• Quickly export relational tables to BSON or JSON documents
  Easier export of relational tables to BSON/JSON format by using the new function genBSON()
• Time series
• Include JSON documents in time series
  A BSON column can be included in a TimeSeries datatype. Ideal for sensors that collect data in BSON format. This can be used through teh REST API
• Enhancements to the time series Java class library
  More usability for java programmers working with TimeSeries data
• Security
• PAM password authentication for DRDA connections
  A specific request from one of "my" customers (A dear customer if I may say so.). It seems weird that we didn't support PAM for DRDA connections. But as you know, PAM is one of my "pet" subjects, so I'd like to explain this. The way PAM is implemented in our engine, we allow the PAM modules to send challenges to the client. The client needs to register a function to handle (answer) these requests. So this means that the database communication protocol must be able to pass through these requests and respective answers. That was not a problem for SQLI which is only used by Informix. But DRDA is used by several databases (Informix, DB2 LUW, DB2 z/OS, DB2i and cloudscape/derby at least. DRDA is also a published standard. So changing it is not trivial. It's not the first time this holds us back, and I'm convinced it won't be the last. The solution was a compromise.... We accept PAM connections in password mode (challenges can't be used). That's not perfect, but it was easy to implement and fitted this customer needs.

Versão Portuguesa
Estou a atrasar-me imenso no meu objetivo de ter um artigo por semana, mas como tem sido hábito... trabalho... Mas não podia deixar passar esta oportunidade. O último fixpack do Informix foi disponibilidade há cerca de duas semanas. E a documentação online e os novos PDFs foram disponibilizados ao mesmo tempo. Tudo em simultâneo como deve ser. Aparentemente isto está a tornar-se um hábito, e embora fosse expectável, nem sempre aconteceu. Por isso sinto-me satisfeito que aparentemente tenham finalmente "entrado nos eixos".
Vou repetir-me, mas sendo verdade não vejo porque o não deva fazer. Mais uma vez temos um fixpack cheio de novidades. Penso que a maioria dos nossos clientes nem se apercebe das mudanças que têm sido introduzidas no produto... E por "mudanças" quero dizer funcionalidades novas, já que as "antigas" continuam lá e de boa saúde. Mas em cada fixpack parece que as potenciais  utilizações e potenciais utilizadores são cada vez mais abrangentes. A IBM está a expandir o Informix para áreas completamente diferentes e novas e atrevo-me a dizer que nenhuma outra base de dados "tradicional" terá visto uma tão grande transformação, ou melhor dizendo, adaptação a novos requisitos e novas realidades como o Informix. Como habitualmente vou pegar na lista de novidades oficial e acrescentar os meus comentários.

• Migração
• Mudanças no servidor * Requisitos de conversão de Enterprise Replication * Requisitos de conversão e reversão de compatibilidade JSON
  Apenas algumas notas que devemos ter em conta ao preparar upgrades e downgrades
• Mais fácil importar tabelas com registos longos
  Uma funcionalidade que tenta evitar obter extents demasiado grandes em tabelas com campos LVARCHAR grandes. Com a nova opção "-D" no dbimport os extnents serão de 16KB. Se me perguntassem, diria que o melhor era a opção permitir indicar o tamanho. Apesar de perceber o problema que está a tentar resolver, diria que 16KB também é demasiado pequeno
• Instalação
• Instalação mais fácil de programas de 32 bits em Windows de 64 bits
  Deixa de haver a necessidade de alterar a PATH antes de instalar uma versão de 32 bits num Windows de 64 bits
• Desinstalação de programas Informix a partir do painel de controlo
  Maior conveniência
• Administração
• Multitenancy no Informix
  Ok... esta merece um artigo exclusivo."tenant" em Inglês quer dizer inquilino, ou arrendatário. Mutitenancy é um termo usado em TI para descrever o "alojamento" ou agrupamento de várias entidades sob uma única entidade de gestão e configuração. Poderá ter notado que um dos nossos concorrentes fez um grande alarido em torno de algo semelhante, e foi anunciado como uma grande funcionalidade (ou A grande funcionalidade) de uma versão principal. Nós introduzimos isto num fixpack discreto. Isto encaixa perfeitamente na imagem global do Informix vs outras bases de dados.
  Basicamente estamos a construir sobre o conceito de uma base de dados dentro de uma instância, algo que sempre suportámos (e já agora o DB2 também). Neste fixpack introduzimos algumas capacidades adicionais: Ter uma classe de CPU VPs e associá-la a um tenant (controlo de recurso de CPU), definir o número de locks por sessão nessa base de dados e associar um conjunto de dbspaces só para ela. Objectos de outras bases de dados não serão aceites neste conjunto de dbspaces, e os objectos desta base de dados não podem ser alocados noutros. No entanto dbspaces temporários podem ser partilhados.
  Se pensarmos sobre isto parece uma simples extensão ao que já existia, ou seja o conceito de base de dados. mas se insistirmos no tema, facilmente encontramos coisas que gostaríamos de fazer com estes novos tenants... algumas poderão ser "emuladas" (estou a pensar num limite de sessões por tenant). Outras nem tanto, como seja limitar a memória ou logical logs usados por cada um. Por isso apostaria dinheiro na ideia que isto será um ponto de evolução permanente a partir de agora.
• Melhorias no OAT
  Como é habitual, novas funcionalidades do motor, implicam novas funcionalidades do OAT. A gestão dos tenants e eliminação de inplace alters pendentes são dois exemplos.
• Mais fácil remoção de inplace alters
  Uma nova função SQL permite eliminar inplace alters pendentes em tabelas. Um inplace alter será o que resulta de um ALTER TABLE que não tenha refeito a tabela. Ou seja, enquanto houver páginas que fisicamente estão na versão anterior, considera-se uminplace alter pendente. A remoção destas situações pode fazer-se com dummy updates (SET col1 = col1 WHERE 1 = 1). Isto evita que durante UPDATES e DELETEs o motor tenha de converter o formato das páginas que contenham registos alterados.
  Esta nova tarefa facilita a remoção destas situações. Como mencionado anteriormente, o OAT pode ser usado para gerir esta tarefa.
• Limitar o tamanho dos espaços de alojamento extensíveis.
  Podemos agora definir um limite máximo para os chunks/dbspaces que estejam em auto extend. Bastante útil em qualquer caso, mas faz ainda mais sentido se conjugado com o conceito de tenants
• Limitar o número de locks  por sessão
  Finalmente esta funcionalidade não documentada torna-se oficial. Pode ser definido no $ONCONFIG ou com a instrução SET ENVIRONMENT
• Novo valor por omissão do parâmetro VP_MEMORY_CACHE_KB
  Este parâmetro específica a quantidade de cache de memória que cada CPU VP pode usar. Foi recentemente estendida para podermos definir com uma segunda opção (DYNAMIC, STATIC) se seria dinâmica ou estática. O comportamento por omissão agora será STATIC (podendo ser definido como DYNAMIC)
• Replicação
• Melhorias no processo de aplicação de dados replicados e na alocação de memória no Enterprise Replication
  Um novo parâmetro CDR_MEM controla a forma como a memória para enterprise replication é alocada. Dois novos métodos fornecem opções que permitem um trade-off entre consumo de recursos e performance.
• Replicação de TimeSeries comprimidos e do tipo hertz
  O ER permite agora replicar hetrz (frequência sub-segundo) e TimeSeries normais comprimidos.Assim ambos podem ser usados em ambientes ER e GRID
• Novo evento com alarme para bloqueios em transações replicadas
  Este alarme irá disparar se houver transações bloqueadas devido à colocação de uma tabela em modo ALTER
• Performance
• Otimizações de storage mais rápidas
  O compress, uncompress e repack podem agora ser executados em paralelo usando a opção parallel das respetivas funções. Isto aplica-se tanto a tabelas como índices
• Queries sobre views com UNION ALL mais rápidas
  Uma otimização que tenta evitar a materialização de views deste tipo. Naturalmente sem materialização as queries poderão correr (muito) mais rápido
• Desenvolvimento de aplicações
• Configuração do tamanho de apresentação dos caracteres de uso privado do UNICODE
  Em princípio a maioria de nós não terá de se preocupar com isto, mas para quem use  Unicode Private Use Area (PUA), as ferramentas em modo carácter permitem agora a especificação da dimensão de cada um desses caracteres. Para o fazer temos de definir a variável de ambiente IFX_PUA_DISPLAY_MAPPING e criar um ficheiro de mapeamento em $INFORMIXDIR/gls/etc/pua.map, indicando para cada carácter a dimensão de apresentação (1 ou 2, sendo 1 o valor por omissão)
• Compatibilidade SQL: cláusula LIMIT permitida depois da cláusula de projeção
  Uma funcionalidade de compatibilidade SQL simples. Já há muitos anos que podemos limitar o número de linhas no resultado de uma query usando a opção LIMIT na cláusula de projecção:
  SELECT LIMUT 2 * FROM systables ORDER BY 1
  Agora podemos também usar o LIMIT como cláusula:
  SELECT * FROM systables ORDER BY 1 LIMIT 2
• Compatibilidade JSON
• Melhorias na compatibilidade JSON
  Como temos visto em fixpacks anteriores, a funcionalidade JSON tem sido um tópico quente. Algumas das funcionalidades introduzidas agora são:
  
• Suporte para cursores de forma a que seja possível tratar grandes quantidades de dados
• Procura de texto em tabelas e collections
• Queries e índices Geo-Espaciais
• Operadores de agregação pipeline
• Modificadores de update de arrays: $each, $slice, $sort
• Importação e exportação de dados directamente com o wire listener utilizando os comandos Informix JSON exportCollection e importCollection
• Configurar uma estratégia para calcular o tamanho da sua base de dados utilizando a estensão Informix ao comando MongoDB listDatabases: opção sizeStrategy ou a propriedade command.listDatabases.sizeStrategy
• Configurar o wire listener através de novas propriedades. Por exemplo:
• logging,
• caching
• timeout
• memory pools
• tamanho máximo dos documentos
• Aceder ao Informix através de clientes de REST API
  O wire listener para JSON pode ser configurado para responder a pedidos REST API. Estes usarão a sintaxe do MongoDB e retornarão documentos JSON. Mas podem aceder a collections MongoDB. tabelas tradicionais e dados TimeSeries
  Isto torna o acesso à base de dados mais simples para casos onde a instalação de drivers e uso das APIs tradicionais seja mais complicado
• Criação de um TimeSeries através a REST API, sobre a MongoDB API
  A API REST pode ser usada para criar um TimeSeries. Antes seria necessário criá-lo com SQL podendo depois usá-lo através do JSON wire listener
• Suporte BTS para dados JSON e BSON
  O Basic Text Search datablade foi estendido para suportar índices sobre dados JSON/BSON. O índice pode ser criado e utilizado tanto via SQL como com MongoDB API. O BTS passa a suportar opções específicas para documentos JSON como já suportava por exemplo para XML
• Aceder a dados BSON de aplicações cliente JDBC
  O driver JDBC fornece agora uma classe de objeto JSON chamada IfxBSONObject
• Exportar rapidamente dados de tabelas relacionais para documentos BSON ou JSON
  Através da nova função genBSON() pode exportar-se os dados de tabelas relacionais, convertendo-os para BSON ou JSON
• Time series
• Inclusão de documentos JSON em TimeSeries
  Pode incluir-se uma coluna BSON num tipo de dados TimeSeries. Ideal para sensores que recolham ou produzam dados em formato JSON. Isto pode ser usado através da REST API
• Melhorias na classse TimeSeires da biblioteca de Java
  Maior usabilidade para programadores Java que trabalhem com dados TimeSeries
• Securança
• Autenticação por password, usando PAM com DRDA
  Um pedido específico de um dos "meus" clientes (um cliente bastante apreciado se o posso dizer). Pode parecer estranho que não suportássemos PAM em conexões DRDA. Mas como saberão, o PAM é um dos meus temas "de estimação" e por isso gostaria de explicar isto. A forma como o PAM está implementado no nosso motor, permite que os módulos PAM enviem "desafios" aos clientes. O cliente tem de registar uma função ou método para lidar e responder a estes desafios. Ora isto implica que o protocolo de comunicação saiba lidar e preveja o envio destes pedidos e respetivas respostas. Issso não foi um problema para o SQLI, que apenas é usado pelo Informix. Mas o DRDA é usado por várias bases de dados (Informix, DB2 LUW, DB2 z/OS, DB2i e  Cloudscape/Derby pelo menos). DRDA é também um standard público e publicado. Assim, mudar o protocolo não é trivial e envolve processos formais e morosos. Não é a primeira vez que isso nos causa problemas e presumo que não será a última. A solução encontrada foi um compromisso... Aceitamos ligações DRDA com PAM desde que estejam em modo "password" (desafios não podem ser usados. Isto não será o ideal mas terá sido (muito) fácil de implementar e foi ao encontro das necessidades do cliente.