Thursday, March 03, 2016

Informix event in Barcelona / Evento Informix em Barcelona

An Informix event in Barcelona (Spain) will take place on March 17 (original version http://informix-technology.blogspot.com/2016/03/informix-event-in-barcelona-evento.html)



English version
The Spanish Informix User Group is organizing an event in Barcelona on March 17 at IBM Client Center.
The event will have the presence of Vicente Salvador and Stuart Littel respectively the presidents of the Spanish and International Informix user groups and several IBM high profile managers and architects. Specifically product manager Jerry Keesee, Sandor Szabo from R&D (involved with Informix Warehouse Accelerator and ARM ports) and  technical product manager Simon (Cosmo) David.
The topics covered will include current status, product strategy, IoT and Timeseries. But naturally it will be a great way to interact with users and IBM personnel.

The details can and registration can be checked here:

http://www.ibm.com/events/informixIBM



Versão Portuguesa
O grupo de utilizadores Informix de Espanha está a organizar um evento em Barcelona no dia 17 de Março, no IBM Client Center.
O evento contará com a presença de Vicente Salvador e Stuart Litel, respetivamente presidentes do grupo de utilizadores de Espanha e do grupo internacional de utilizadores Informix e vários responsáveis e arquitetos da IBM. Especificamente estarão presentes o gestor de produto Jerry Keesee, Sandor Szabo do desenvolvimento (envolvido com o Informix Warehouse Accelerator e as versões para processadores ARM por exemplo) e Simon (Cosmo) David, um gestor técnico de produto.
Os tópicos das sessões passarão pela situação atual, a estratégia para o produto, IoT (Internet das coisas) e Timeseries. Mas naturalmente será também uma excelente oportunidade para contactar com utilizadores e pessoal da IBM.

Os detalhes podem ser consultados no endereço seguinte, bem como o registo no evento.

http://www.ibm.com/events/informixIBM

Thursday, February 25, 2016

Technical support changes

Uniformization of IBM technical support procedures (original version http://informix-technology.blogspot.com/2016/02/technical-support-changes.html)



English version
A few IBM notes were published regarding upcoming technical support changes that will be effective on March 7. The main note is here:

http://www.ibm.com/support/docview.wss?uid=swg21977359

It contains two links to more detailed information. In a very short summay the changes will be:

  1. An existing phone number is going to be discontinued and replaced by the generic IBM support number
  2. The previous possibility of tranferring the call to a support engineer (if one was available) will be replaced by the generic call back procedure (within the response time goals stated in the support handbook

Wednesday, February 24, 2016

Scripts distribution / Distribuição de scripts

My scripts are now live on GitHub (original version here)


English version
People following this blog or my posts in comp.databases.informix or in the IIUG mailing lists may have noticed I've been working with Informix for a couple of decades (actually a bit more). Over this period, I, as any Informix DBA have created and used a few utility scripts and code.

Several years ago I decided to use a version control system to manage these sources essentially as a way to keep track of versions and changes. The main driver to this was that I occasionally left some of these scripts in some customers who eventually later got in touch with me to report doubts or issues. Sometimes it was hard to understand the version they were using so that I could understand if the problem or doubt would still be meaningful in the latest versions.
After looking around I decided to use CVS for it's simplicity and because I didn't need any fancy distributed version control system.

Later I decided to make the scripts generally available and over time I got a VM running on my home computer with ViewCVS installed. This is a handy little utility that will present a web interface over a CVS repository. Simple to setup it worked great, as long as the VM was running, my Internet provider was ok, and I could update my dynamic DNS service if my IP changed. As you can imagine, several potential points of failure resulted in the unavailability of the system for long periods.

Just recently I decided I needed to fix this. So I looked around for public source codes repositories that could be used. For several reasons GitHub was the natural choice (basically too much uncertainty around other options and some security issues). But if from a hosting point of view GitHub was a good choice, from some other practical aspects is was a nightmare:

  • It's a nice distributed version control system, created for easy collaboration between many developers spread across geographically disperse regions. A simple automatic feature of CVS which is to mark a file with a specific version on each commit, one that can be easily readable by an end user, is not possible (nor really needed in a traditional project where there is a "build" phase) with Git.
  • The concepts are a bit more complex (to say the leastt), given the objectives. For my use case this is completely overkill
  • GitHub offers also an SVN (another version control system) option, but converting to SVN would still require significant changes on the way I work
  • I wanted to convert my CVS repository to a new system, without loosing the history of changes

After a couple of weeks messing around with GitHub and a nice CVS2Git conversion utility I'm glad to announce I've done it.

From now on, my work with Informix scripts will be available on:

http://github.com/domusonline/InformixScripts

You can browse it, download the scripts and even clone the repository for your use. Currently I have no plans to include collaborators on this repository (people who would be able to submit changes made by them to the scripts). There are several reasons why:
  • I don't have available time to guarantee good support for this to work out well
  • I don't think this is really need. I highly doubt there would be requests in a significant number to justify this
Having said this, by no means I'm stating I'm not interested in improving the scripts. Quite the opposite. If you use any of them and find a bug or have doubts please send me feedback, or propose changes and I'll do my best to answer in a timely manner. I just can't guarantee anything. GitHub has a nice feature that allows users to create issues, make requests etc.
In any case the scripts are made available as GPL version 2 license You can use them and change them.

Things to do and caveats
Many of the scripts are a bit useless without some documentation or guidance. Not that they are very complex, but some of them have some assumptions and dependencies on other scripts. I'll try to document the ones that really need documentation. I'll try to do this in two ways:
  • Add the documentation to GitHub, either in it's wiki or with README files
  • Eventually post here some articles about some of the scripts

In any case, most of the scripts (the most useful ones I'd say) are self contained and will show you the usage if you run them with the "-h" option.

Feel free to access the repository, download the script you feel could be useful and send me feedback about problems, suggestions etc




Versão Portuguesa
Quem siga este blog ou as minhas participações no comp.databases.informix ou nas listas e email do IIUG, já terá percebido que trabalho com Informix há um par de décadas (um pouco mais na verdade). Durante este período eu, como qualquer outro DBA Informix, criei e usei algum código e scripts.

Há vários anos atrás decidi que deveria utilizar um sistema de controlo de versões para gerir estas fontes, essencialmente como uma forma de manter um registo de versões e modificações. A principal motivação para isto foi que ocasionalmente deixo alguns destes scripts em clientes que visito, os quais eventualmente mais tarde me contactam com dúvidas ou problemas. Por vezes era difícil perceber que versão estavam a usar de forma a perceber se o problema ou dúvida ainda fazia sentido nas versões mais recentes.
Depois de procurar decidi usar o CVS,pela simplicidade e porque não necessitava de funcionalidades "finas" oferecidas pelos sistema de controlo de versões distribuídos.

Mais tarde decidi que deveria disponibilizar os scripts e acabei por ter uma VM a correr no PC caseiro com o ViewCVS instalado. Este componente é um pequeno software que disponibiliza uma interface web sobre um repositório CVS. É simples de montar e funciona bem, desde que a VM esteja a correr, que o meu serviço de internet esteja estável e que eu consiga atualizar o serviço de DNS dinâmico em caso de mudança de IP. Como se pode imaginar, vários potenciais pontos de falha resultaram em indisponibilidade durante longos períodos.

Mais recentemente decidi que deveria resolver isto. Procurei por serviços de repositórios públicos e gratuitos. Por várias razões o GitHub foi a escolha natural (basicamente devido a incertezas e problemas de segurança associados a outras alternativas). Mas se do ponto de vista do alojamento o GitHub é uma boa escolha, de outros pontos de vista mais práticos foi um pequeno pesadelo:

  • É um excelente sistema distribuído de controlo de versões, criado para fácil colaboração entre muitos programadores espalhados por diferentes áreas geográficas. Mas uma simples funcionalidade do CVS, que "marca" cada fonte com uma versão ou revisão específica durante um commit não é possível (nem é realmente necessária num projeco tradicional onde exista uma fase de "build")
  • Os conceitos são um pouco mais complexos (para não dizer mais), especialmente considerando os objectivos. Para o meu caso de uso é um "exagero".
  • O GitHub também oferece uma opção de usar o SVN (outro sistema de controlo de versões). Mas a conversão para o SVN revelou-se também trabalhosa
  • Queria converter o repositório sem perder o histórico das alterações
 Depois de um par de semanas às voltas com o GitHub e um simpático software de conversão, o CVS2Git, é com satisfação que anuncio que está feito.

A partir de agora, o meu trabalho em scripts relacionados com Informix estará disponível em:

http://github.com/domusonline/InformixScripts

Pode navegar no repositório, transferir os scripts individualmente ou até clonar o repositório para seu uso. Neste momento não tenho planos para incluir colaboradores neste repositório (pessoas que poderiam fazer envios de alterações). Há várias razões para isto:
  • Não tenho disponibilidade de tempo para garantir um nível de suporte que permitisse o bom funcionamento do processo
  • Não me parece que seja realmente necessário. Dúvido sinceramente que houvesse pedidos num número que justificasse isto
Tendo dito isto, não quero dizer de forma nenhuma que não esteja interessado em melhorar os scripts. Muito pelo contrário. Se usar algum deles e encontrar um problema, ou se tiver dúvida por favor envie-me feedback ou proponha alterações que eu farei o meu melhor para responder atempadamente. Apenas não posso garantir nada. O GitHub tem uma funcionalidade simpática que permite que os utilizadores possam criar "issues" que podem ser comentários, relatos de erros, pedidos de funcionalidades etc.
Em qualquer caso os scripts são disponibilizados sob a licença GPL versão 2. Pode usá-los e alterá-los.


Alterações e problemas
Muitos dos scripts são um pouco inúteis sem alguma docuemntação ou aconselhamento. Não que sejam muito complexos, mas alguns deles partem de certos pressupostos, ou têm dependência de outros scripts. Tentarei documentar os que realmente necessitam de documentação. Isto poderá ser feito de duas formas:
  • Adicionar documentação ao GitHub, seja na forma do Wiki ou em ficheiros README
  • Eventualmente através de alguns artigos aqui no blog

De qualquer das formas, a maioria dos scripts (os mais úteis diria eu) são independentes e mostram alguma ajuda se executados com a opção "-h"

Esteja à vontade para aceder ao repositório, descarregar os scripts que lhe possam ser úteis e envie-me feedback sobre problemas, sugestões etc.

Sunday, December 06, 2015

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