Informix 12.10.xC6 is out! / Saíu a versão 12.10.xC6
The xC6 fixpack of version 12.10 is out. Chek out it's features (original version here)
English version
Nearly ten months after the last article... that's probably my worst record. I'm not proud, but as usual there were reasons. Be sure that I haven't left Informix, nor Informix left me... I believe I have some on it in my blood stream. But in fact besides some regular activities on some customers I was tied on some non Informix projects. The fact is, because it just runs and due to it's simplicity, customers don't need too much help. But after some stressing engagements I'm able to breed again, and just in time to pick up with a new Informix release. I always repeat the same idea, which is that for several years we have adopted the "agile" methodology which means we're faster to deliver new features to market. This release is not an exception and as usual I'll post the official list with my unofficial comments:
- Server changes
- Support for additional platforms
Informix is now available on IBM POWER8® for ppc64le with Red Hat Enterprise Linux 7.1, SUSE Linux Enterprise Server 12, and Ubuntu 14.04 LTS;
These are the "little endian" versions of Linux on Power8 processors which I mentioned in a previous article. Note the "ppc64le" designation - Spatial datablase available in new platforms
IBM Power Series® 64-bit with Red Hat Enterprise Linux ES releases 5.3, 6, and 7, and SUSE SLES 11
IBM zSeries 64-bit with Red Hat Enterprise Linux ES releases 5.3 and 6, and SUSE SLES 11 - Administration
- Multitenancy
- Limit shared memory and connections for tenant databases
Two new parameters (TENANT_LIMIT_CONNECTIONS and TENANT_LIMIT_MEMORY) or tenant options allow the definition of memory and number of connections per tenant. When the memory limit is reached the session using more memory will be killed. - Restore tenant databases to a point in time
I can't underline enough how important this feature is. Some custumers have been asking this for years. They usually argued that they should be able to keep their databases in a single (or a set) dbspace, so that they could restore just that dbspace to a point in time (PIT). The problem in allowing that was that Informix had no way to guarantee that the dbspace or set of dbspaces didn't contain objects from another database on the same instance. So doing a PIT could cause inconsistencies on the database and as a general rule we don't allow it. But once tenants were introduced that basic issue was solved, and I was really expecting this to appear in some fixpack. - Backup and restore
- Control restore resources
A new parameter, BAR_MAX_RESTORE allows us to define the number of parallel processes doing a restore. It acts like BAR_MAX_BACKUP. - JSON compatibility
- Parallel sharded queries
A sharded query, that is, a query that accesses a sharded table can now run in parallel. The best explanation for this is this really cool video:
- MongoDB 2.6 and 3.0 compatibility
Nev features introduced in versions 2.6 and 3.0 of MongoDB are now supported. For a full list please consult the documentation - Wire listener enhancements
Several improvements around security and resource management. - Authenticate wire listener connections with Informix
The mongodb users can have their identity checked by the database server. This means the operations will be done as a specific user and not a generic user defined in the connection URL from the listener to the database. All user activity can be controlled and audited with greater granularity - High availability
- Faster communication between high-availability servers
A new parameter, SMX_NUMPIPES can be used to define a number of parallel connections for HA servers using the SMX mechanism. This can lead to better performance and less latency in the communications - Faster index transfer to secondary servers
When an index has to be sent to a secondary server using the LOG_INDEX_BUILD option (always for RSS and to HDR when LOG_INDEX_BUILD is set), can use light scans (reads that don't go through the buffer cache) whenever possible - Easier cloning of database servers
A new ifxclone parameter (--createchunkfile) allows the automatically creation of the chunks and mirror chunks on the secondary server. - Application development
- JDBC
- Reoptimize JDBC queries
Second best thing in this version. A typical problem with PREPARED statements is that sometimes a query is done with a parameter that makes the "natural" query plan very slow. For example when 50% of a table has many values for a column, but the rest 50% has only one value. Use that column index can be a good thing for the first case and a nasty thing for the second. Many times this is known by the application, and if the query contains those "bad filters" a new argument (withReoptimization) of the IfmxPreparedStatement.executeQuery() method can be used to force the query plan recalculation.
This is a very typical and common problem which I faced several times. For years we have this functionality in 4GL ( {OPEN|FOREACH} ... WITH REOPTIMIZATION) - Keep JDBC socket connections open
A new JDBC property (IFX_SOC_KEEPALIVE) was introduced to solve a very common issue in application server connections to the database when there's a firewall in the middle. Actually the last article I was writing before my long "winter" was about this issue but I never published it. I started it around February/March this year because I faced it in a Spanish customer. There were other solutions to solve this, but this one is very simple. When we define this new property we're actually asking the operating system to activate a TCP/IP functionality called KEEPALIVE. We can do that with an option in SQLHOSTS (k=1) but usually JDBC connections don't use SQLHOSTS. So that was an issue. Now it's solved. The idea is to prevent the firewall to close the connections due to inactivity - SQL
- Avoid caching SQL statements with unpredictable query plans
A new optimizer directive (AVOID_STMT_CACHE) can be used to mark an SQL statement as "non cacheable". I'm usually against the use of optimizer directives, but sometimes they're useful... - Performance
- Prioritize databases for automatic update statistics
A DBA can assign three different levels of priority for a database withing the Automatic Update Statistics system. This can help to make sure more important databases will be worked first, and if the time window for AUS allows, then the other less priority will be run. - Security
- Audit Informix databases with IBM Security Guardium
In my humble opinion this feature is very badly documented. It gives the idea that now we can use Guardium to audit Informix. In fact Guardium supports Informix for many years (even before IBM acquired Guardium). The new thing here is that we now allow a "communication exit" mechanism to inter operate with Guardium as DB2 has. This allows for some extra Guardium functionality to work with Informix (like the ability to stop/prevent a query from running based on some criteria, redaction, query re-write etc.) - Time series data
- Show time series reference count
TSInfo() now shows the number of rows in a timeseries table that reference the TS container - Default dbspace for time series containers
If we now specify NULL for the TS containers storage when using the TSCreateContainer() procedure, they will be created in the dbspace where the table is located or in the tentant's catalog dbspace - Warehousing
- Enhanced monitoring of IBM Informix Warehouse Accelerator queries
A new ondwa option "tasks" will show information about current and queued queries.
Versão Portuguesa
Quase dez meses depois do último artigo... é provavelmente o meu pior record. Não me orgulho, mas como habitualmente houve razões. Tenham a certeza que não deixei o Informix, nem o Informix me deixou... Penso que tenho algum a correr-me no sangue. Mas é um fato que para além de algumas atividades regulares em clientes habituais, estive "preso" em alguns projetos não relacionados com Informix. Na verdade, porque o Informix simplesmente funciona, e devido à sua simplicidade, os clientes não necessitam de muita ajuda.
Mas depois de alguns projetos bastante stressantes, consigo respirar outra vez e mesmo a tempo de pegar numa nova versão do Informix. Eu repito sempre a mesma ideia, que é a de que de hà uns anos a esta parte a IBM ter adotado a metodologia "agile" o que significa que somos mais rápidos a disponibilizar novas funcionalidades ao mercado. Esta versão não é uma exceção e como é habitual vou seguir a lista oficial e adicionar os meus não oficiais comentários:
- Mudanças no servidor
- Suporte para plataformas adicionais
O Informix está agora disponível em IBM POWER8® para ppc64le com Red Hat Enterprise Linux 7.1, SUSE Linux Enterprise Server 12 e Ubuntu 14.04 LTS
Estes ports são versões "little endian" do Linux para processadores POWER8, que já referi num artigo anterior. Note a designação "ppc64le" - O datablade Spatial está disponível em novas plataformas
IBM Power Series® 64-bit com Red Hat Enterprise Linux ES releases 5.3, 6, e 7, e SUSE SLES 11
IBM zSeries 64-bit com Red Hat Enterprise Linux ES releases 5.3 e 6, e SUSE SLES 11 - Administração
- Multitenancy
- Limitar a shared memory e o número de conexões am bases de dados tenants
Dois novos parâmetros (TENANT_LIMIT_CONNECTIONS e TENANT_LIMIT_MEMORY) ou opções dos tenants permitem definir a memória e conexões por tenant. Quando a memória é atingida a sessão com maior utilização de memória é eliminada - Restaurar bases de dados tenant para um ponto no tempo
Não consigo sublinhar devidamente a importância desta funcionalidade. Alguns clientes têm vindo a pedir isto há anos. Normalmente argumentavam que deveriam poder ter uma base de dados num só dbspace (ou num conjunto de dbspaces), e depois deveria ser possível fazer um restore PIT. O problema em permitir isto é que o Informix não tinha forma de garantir que esse(s) dbspace(s) não continha(m) objectos de outras bases de dados da mesma instância e portanto a ação de restore poderia causar inconsistências, e na generalidade não permitimos isso. Mas após a introdução dos tenants esse problema estava resolvido e estava realmente à espera que esta funcionalidade surgisse - Backup e restore
- Controlo sobre os recursos de restauro
Um novo parâmetro, BAR_MAX_RESTORE permite definir o número de processos em paralelo que trabalham para o restore. Funciona tal como o BAR_MAX_BACKUP. - Compatibilidade JSON
- Queries sharded em paralelo
Uma sharded query, ou seja uma query que acede a uma sharded table pode agora ser executada em paralelo. A melhor explicação para esta funcionalidade é este interessante vídeo::
- Compatibilidade MongoDB 2.6 e 3.0
Novas funcionalidades nas versões 2.6 e 3.0 do MongoDB são agora suportadas. Para uma lista detalhada consulte a documentação - Melhorias no Wire listener
Várias melhorias em termos de segurança e controlo de recursos - Autenticação de ligações via wire listener no informix
Os utilizadores que acedem via a API do MongoDB podem agora ser autenticados no Informix. Isto significa que as operações na base de dados serão efetuadas com o utilizador da aplicação e não com o utilizador definido no URL de conexão ao Informix via wire listener. As ações dos utilizadores podem ser controladas e auditadas com muito maior granularidade - Alta disponibilidade
- Comunicação mais rápida entre servidores configurados em alta disponibilidade
Um novo parâmetro, SMX_NUMPIPES, pode ser usado para definir o número de canais paralelos de comunicação entre o servidor principal os secundários que usem o mecanismo SMX. Isto pode melhorar a performance e ajudar a baixar a latência - Transferências de índices mais rápidas para os servidores secundários
Quando um índice tem de ser enviado para um servidor secundário utilizando a opção de LOG_INDEX_BUILD (sempre para servidores RSS e para os HDR quando a opções está ativa), o motor tentará usar light scans (leituras que não passam pela buffer cache) - Clonagem de servidores facilitada
Um novo parêmetro (--createchunkfile) do utilitário ifxclone permite a criação automática de chunks e respetivos mirrors no servidor de destino - Desenvolvimento aplicacional
- JDBC
- Re-otimização de queries JDBC
A segunda melhor funcionalidade desta versão. Um problema típico de instruções PREPAREd é que por vezes uma query executada com um argumento específico pode transformar um plano de execução correto num que é uma péssima escolha. Tomemos por exemplo um caso em que 50% de uma tabela tem muitos valores para uma coluna, mas que nos restantes 50% tem sempre o mesmo valor. Utilizar um índice nessa coluna pode ser uma boa opção para os valores dispersos, mas será uma má opção se o valor do filtro for o valor que se repete muito. Muitas vezes a aplicação "sabe" quais os valores maus, ou quais as queries em que isto pode acontecer. Para essas situações temos agora um novo argumento (withReoptimization) do métofo IfmxPreparedStatement.executeQuery() que pode forçar nova criação do plano de execução
Isto é um problema típico e muito frequente que já encontrei diversas vezes. Temos esta funcionalidade no 4GL há anos com o {OPEN|FOREACH} ... WITH REOPTIMIZATION, e agora passa a haver um equivalente para JAVA - Manter os sockets de conexões JDBC abertos
Uma nova propriedade de JDBC (IFX_SOC_KEEPALIVE) foi introduzida para resolver outro problema muito comim nas conexões feitas por servidores aplicacionais quando existe um firewall entre a base de dados e o servidor aplicacional. Curiosamente, o último artigo em que comecei a trabalhar antes do meu longo "inverno" era exatamente sobre este tema.Comecei em Fevereiro ou Março porque me deparei com o problema num cliente em Espanha. Existiam outras soluções para resolver isto, mas esta é muito fácil de implementar. Quando definimos esta propriedade estamos na verdade a pedir ao sistema operativo que active a funcionalidade chamada habitualmente de KEEPALIVE. Podemos fazer isto muito facilmente com uma opção no SQLHOSTS (k=1) mas habitualmente as conexões JDBC não usam o SQLHOSTS. Por isso tornava-se um problema. Agora está resolvido. A ideia é que o firewall não feche as ligações por inatividade - SQL
- Evitar fazer cache de instruções SQL com planos suspeitos
Uma nova diretiva de optimizador (AVOID_STMT_CACHE) pode ser usada para marcar uma instrução SQL como não "cacheable". Isto evita que a instrução seja candidata a ficar na cache de instruções. Normalmente sou contra o uso de diretivas de optimizador, mas ocasionalmente são úteis e é sempre preferível ter opções. - Performance
- Prioridades nas bases de dados para cálculo automático de estatísticas
Um DBA pode atribuir diferentes prioridades a uma base de dados na funcionalidade de Automatic Update Statistics. Isto pode ajudar a garantir que as bases de dados mais importantes são trabalhadas primeiro deixando as menos prioritárias para o final da janela de execução definida - Segurança
- Auditar bases de dados Informix com IBM Guardium
Na minha humilde opinião esta nova funcionalidade está mal descrita. Dá a ideia que agora se pode usar o Guardium para auditar o Informix. Na verdade isso já acontecia há muitos anos (mesmo antes da IBM adquirir o Guardium). A novidade aqui é que agora é permitido uma funcionalidade designada por "communication exit" que permite a inter-ligação com o Guardium, tal como já acontecia com o DB2. Isto permite algumas funcionalidades extra no funcionamento do Guardium com Informix como a possibilidade de parar/impedir uma query baseado num determinado critério, usar data redaction, re-escrever queries etc.
- Time series
- Mostrar a contagem de referências em containers
A função TSInfo() agora mostra o número de linhas numa tabela com timeseries que referencia um TS container - DBSpace por omissão para containers timeseriesSe usarmos NULL para o container de TS quando usamos o procedimento TSCreateContainer(), será criado no dbspace onde existe a tabela ou no dbspace onde está o catálogo no caso de ser um tenant
- Warehousing
- Melhoria na monitorização de queries do Informix Warehouse Accelerator
Uma nova opção "tasks" do comando ondwa mostra informação sobre queries actual e em fila
Posts
