My feature wish list / A minha lista de funcionalidades que faltam

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version

Disclaimer
Again, although I have a clear disclaimer on the side, the following does not represent my employer views and in no way is related to any current plans or roadmaps. In fact this is probably the post where I'm closer to the customers than ever.

Why I'm writing this?
I started this article even before v12.10 was out. Due to some constraints I kept the article in draft for a few months. Now is a great time to publish it. The reason for this is that IBM has done an extraordinary thing (not so recently...): It created and made available a platform where customers can make requests for enhancements in some (the list is increasing) of the IBM portfolio products. And guess what? Informix is already there.
I must admit that I have great expectations and I'm pretty enthusiastic about this initiative, for a number of reasons:

• It's a direct link between customers and IBM. Tell IBM exactly what you need and why... No messing around with sales reps that have other priorities, no PMRs, no user groups filtering
• Being a Web platform it's easy and very quick to use. It allows insertion, voting, subscribing to updates, commenting and so on... The list of features is fantastic
• Means IBM is willing to take some risks: If a feature is highly requested/voted and seems easy to implement, it will be harder to explain why it's not implemented (keep in mind that resources are always insufficient...)
• It's public... again this is a risk for IBM.

All this brings some drawbacks:

• If IBM takes requests seriously (and naturally I believe and hope it will), it may interfere with a more integrated and planned approach to deliver new features
• There will be many requests which are badly explained, or that aren't clear enough, or that simply can be done in other ways. These will consume resources to filter and may possibly obfuscate the really interesting (note the subjectivity in this sentence) features
• It may expose product limitations to competitors (again I think this a very courageous initiative)

Having explained all this, the link to the site was added to the list on the side of this blog. At the time of this writing there are already 74 requests for Informix. I must admit I've added some. The success of this process will depend on customer participation. Review the requests, select the ones you like, vote for them, comment as you think appropriate and create a "watch list" so that you're notified of changes. And of course, add your own if the features you dream about aren't' already there.
I think of this article as a public reflection about functionality I feel is missing currently in Informix. This comes from several customer engagements but are not easy to put into formal feature requests, essentially because those would require a proper business case. So, this is my personal view and feelings, but these are of course influenced by my customer assignments. Meanwhile I'll try to stick with what seems to me as feasible technical features. I'm leaving out stuff like "I'd like Informix to be the market leader", "I'd like to see application provider XPTO supporting it" etc.

Naturally, since I don't work in product development, my thoughts about some of these features feasibility are merely speculation. I'm not able to quantify them in terms of man hours needed to implement and support them. So take all this more like a brain storm. And if you like some of them, vote for them in the site, push for them however you can (IIUG meetings, customer advisory boards, PMRs, through sales representatives, during beta testing programs etc.) Bare in mind that the good people in R&D surely have a lot on their minds, but not necessarily everything we want or need. And of course, since resources are scarce, they must establish priorities. For that they must receive feedback from the field.
For each feature I'll try to give my idea on how it could be implemented and if this would involve a big development effort (with the limitations stated above). Note that the order presented does not represent a priority order

My personal wish list:

1. Have the engine automatically "upgrade" the statistics during/after conversion/upgrade
• Description
  We've always had the easiest upgrades in the marketplace. And CONVERSION_GUARD added an unprecedented confidence level to it. But we still require UPDATE STATISTICS to be run after the conversion. Doing it for the procedures is usually very fast. But for all the tables can take a long time (an experienced DBA knows several ways to speed them). I would like to see the engine "upgrade" if needed the existing statistics. This should be done only when the statistics format change (which I believe is rare). If the data collected in the new version doesn't exist in the old version, than the engine should work without them. The purpose of this would be to be able to open the database for the applications as soon as the conversion ends (typically after a few minutes only).
• How to do it
  I really don't know. To be honest I really don't know if this is really necessary. How often do the statistics format change? Not many I suppose. The idea of this feature is to make this a supported mechanism that would not require full statistics recalculation. Naturally if the new version gathers more info, the optimizer could possibly miss some info required to achieve the best query plan (but should at least achieve the best ones from previous version)
• Benefit
  Reduce the time for doing a supported upgrade into a few minutes. I know...we can do upgrades of MACH-11 clusters with no downtime, but the way we do that is complex (not from the user perspective, but from the engine perspective). And not everybody uses MACH-11
2. Allow setting up MACH-11 secondary nodes on heterogeneous platforms
• Description
  Currently we can only have HDR/RSS nodes on the same platform as the primary server. There are good reasons for this and I probably don't know all of them. But some of these are:
• We need a "bit by bit" image on the secondary nodes. So, platform Endianess becomes an issue
• We need exactly the same layout, so different page sizes becomes an issue
• Even if IBM could fix both issues above, there would still be problems for 3rd party extensions (datablades) than implement their own datatypes and operations
• How to do it
  This is the point where my technical ignorance on several implementation aspects raises the risk of saying something really stupid. But I think the first two issues above could be solved. Regarding the endianess, we should take that into account when sending information between the nodes. I believe this is already done for several aspects of the engine (Enterprise replication, distributed queries etc.). With that in mind, I think it would be possible to transform the information, so that although physically different (byte order could change), the "bit by bit image" would be established at a level above, in the Informix low level access mechanisms (reading/writing to disk). Of course this would have to be implemented in every aspect of the engine used to establish and run HDR/RSS nodes (log shipping, backup/restore, ifxclone etc.)
  Regarding the page size, this is a limitation, but in reality there are only two default page sizes: 4KB used in AIX and Windows, and 2KB used in all the rest (which are not many - HP-UX, Solaris, Linux....?). Why not let the user define the default page size when creating an instance? Assuming he defines 4KB, it would be acceptable in every platform. So the user would have to consider this before creating the instance.
  The last issue, which relates to 3rd party extensions, I'd assume that as a limitation. If the 3rd party implements the needed mechanisms to take the other issues into account, than fine, it would be supported. Otherwise it wouldn't. My point is that those 3rd party products are not widely used
• Benefits
  I think it's easy to explain... Currently a platform change requires some export/import method, enterprise replication or distributed queries to move the data. With the possibility of having HDR/RSS nodes on different platforms this would be achievable in the easiest manner (there is nothing easier to setup than HDR) and with no down time at all
3. Allow upgrades of secondary servers without having to restore from the primary
• Description
  Currently the only supported way to upgrade a secondary server (HDR or RSS) from version A to B, is to install version B and restore from the primary. In some scenarios, when the servers are close together, this can be achievable in very reasonable time. But for geographically distant servers, this is a real problem. To give you an example we have a customer with a 6TB database... It takes a very large amount of time to take those 6TB from place A to place B. If for a primary server you can do the upgrade in a few minutes, for a secondary server it can be a nightmare
• How to do it
  This would be harder than what I'll explain here, but I believe it would be feasible and it would be a great feature for customers. First, the primary would need to be upgradable without loosing awareness of the secondary servers. Then, assuming we're upgrading a sever which is a primary server in a MACH-11 cluster, it should be able to save all the new page images (of changed pages during the conversion) in the file system. Very similar to what we do in the CONVERSION_GUARD feature. But instead of the original image, we should store the new image. After this, we should start the secondary with the new version. Once it started it should notice that it's not running the previous version. As such it should ask the primary if it's on the same new version. If it is, it should ask if the primary has the "changed pages stored". If yes, it should accept the transfer of those pages and store them on the local storage. After that it should continue working as before. I can spot a problematic point... This would probably not work if the nodes were not synchronized before the primary conversion started... So some restrictions or mandatory steps could be implemented
• Benefit
  Allow upgrades in MACH-11 clusters without the need to re-transmit the whole instance image to the secondary locations
4. Expanding the audit trail format
• Description
  I've already made some requests in order to get more information in the audit logs. But R&D has problems because that would break compatibility. I appreciate this concern, but it really limits the ability to use the audit system
• How to do it
  Have some sort of mechanism that would allow the DBA to define what he wants in the audit trail. The easiest way would be to have some form of audit log versioning and have the DBA choose the version he wants (default could be the "classic"). The hardest one, but much more flexible would be to allow the DBA (better saying the DBSSO) to specify what info he wanted for every action mnemonic. This could be defined based on a predefined default that could be changed in some graphical tool (OAT?). The result could be an XML file with the specification. For example, for RDRW, INRW, DLRW and UPRW the user could eventually specify the full row. I would be happy with anything between the easiest (pre-defined formats that could change with versions) and full customization for each mnemonic
• Benefit
  Allow better usage and increase acceptance of the audit system
5. Trusted context should allow "remote" operations
• Description
  Trusted context is a nice feature, and 4GL web services should be able to take advantage of it. But when you're inside a trusted context and you change user identity, you're not allowed to execute remote operations. This happens because of a very good reason (security). The new identity may have been granted some privileges on a remote database, and you, as a privilege local user could create a trusted context, change the identity, and by doing so, abuse the remote privileges granted to that user. So why am I complaining? Because in real life, many of our customers have created several local databases (in the same instance) and their applications require the users to be able to run distributed (local to the instance) queries. So effectively many of them cannot use trusted contexts
• How to do it
  Allow a local DBSECADM to relax the security, allowing the users to do "remote" operations, that are local to the instance. This could be achievable through a new parameter (global to the instance) or a database option (configurable through SQL)
• Benefit
  Turn trusted context feature into something really usable by the majority of customers. Currently I believe it isn't, because many of them want to re-use 4GL business rules inside web services, and their databases require the connection to use the end user identity (because they implemented trigger based logging etc.). Using the end user identity in web services would work better on a trusted context to avoid contant connection establishement
6. Be able to flush any of the internal caches
• Description
  We can flush the statement cache, but we cannot flush the distribution cache, the dictionary cache etc. Although it's true we should not need this, I've faced two bugs and an unknown situation where I needed to flush some of these (procedure, distribution and dictionary cache). The bugs were reported and fixed. But as a workaround it would have been nice to have this
• How to do it
  Implement some new onmode options, and/or SQL API. It could simply flush the cache (simpler to implement I suppose, but with serious impact), or allow us to remove a certain entry (harder to implement I suppose, but with less impact on a running instance)
• Benefit
  Avoid some problems typically caused by bugs. On the absence of this the other options we have are stopping the instance or try to saturate the cache so that the entry in question is kicked out. This is usually very hard to achieve although it's possible.
7. Be able to flush the resolver cached entries
• This was extensively explained in a previous post. The problem summary is that currently we don't have a way to change the DNS servers without stopping the instance.
• How to do it
  Force all MSC VPs to call the OS function res_init()
• Benefit
  Avoid down times in case of DNS infra-structure changes
8. Eliminate the restrictions on DRDA
• Description
  Currently we have two protocols to talk to Informix. SQLI and DRDA. DRDA is the protocol used by the common client and allows connections to DB2, Informix and other DBs. Unfortunately DRDA still has some limitations like some specific Informix datatypes etc. This may prevent it's general adoption by customers. And since many IBM products are using DRDA to talk to DB2, this could make it easier to get those products working with Informix (the ones which still don't)
• How to do it
  This is a complex task. It could eventually require changes in the DRDA protocol. So, this is really a "wish"...
• Benefit
  Take advantage of some functionality of DRDA not present in SQLI. Allow more easy portability of some products to work with Informix
9. Extend FORCE_DDL_EXEC to all Informix DDL
• Description
  In 11.50 we introduced this environment setting to force an ATTACH/DETACH FRAGMENT, meaning any other transaction preventing it will be aborted. Any DBA on a complex system immediately started to cry for this in every DDL statement like ALTER TABLE, CREATE/DROP TRIGGER etc.
• How to do it
  Extend the current implementation to all the other scenarios. I really have no idea of the work involved and the implications this might have
• Benefit
  Make it easier running DDL on a busy system. Typically DBA spend more time trying to free some table than to apply the change itself
10. Parallel scans on non fragmented partitions
• Description
  We only launch one scan thread per partition, because we assume it's located in a disk and we don't want the disk heads jumping around like crazy. But this is currently outdated because of the changes in the concept of "disk" (with the SANs and the stripes etc.). This can slow us down in many situations, when we could take advantage of the parallelism embedded in the engine 
• How to do it
  We could link this to IMPLICIT_PDQ, or create some other form of control (if PDQPRIORITY is set and the table is larger than X etc.). Once we calculate the correct parallelism, the single partition would be virtually split into smaller pieces and each one should receive it's scan thread
• Benefit
  Much faster queries on non partitioned tables (if PDQ or IMPLICIT_PDQ) were set
11. Be able to get the query plan in simple text in the session sending the query (just a simple view)
• Description
  Currently we need to write the query plan to a local database filesystem, or to use a tool that can show the visual explain. I'd like to see functionality inside the engine that would convert the XML file generated by the EXPLAIN_SQL() function into simple text and make it available in a session view
• How to do it
  I've created a proof of concept and presented it in 2010 IIUG conference. But due to lack of time and some technical issues I could not pursue this. Later I worked on a very usable (I'm biased obviously) alternative. But it still is a workaround
• Benefits
  Obtaining a query plan should be a trivial task for any user connecting to the database. Currently it isn't.
12. Be able to get the query plan of a running query
• Description
  The DBA should be able to easily obtain the query plan of a running query. This is more or less possible (xtree), but the result is less than satisfactory. Other options would need to have some features activated (SQL Trace)
• How to do it
  Implement some sort of EXPLAIN_SQL() that instead of a query text receives a session ID, or other simple way to specify the running query. It should/could also be associated with onstat -g pqs (that although sometimes useful was clearly not done for the DBA - I assume it was designed as a support function). For older guys, xtree almost does this, but the output is not clear enough and it requires x-windows
• Benefit
  Increase DBA productivity. We should be able to easily understand why a current session is slow. Currently it's a bit of guess work
13. Implement session limits and priorities
    • Description
      We should be able to limit several session limits (memory, locks, logical log space, cpu usage etc.). Some of this are already implemented, some have been talked about and others seem to be relatively easy. Take CPU usage for example... We already have threads, and there are different priorities for them. Just create an interval for normal user threads and let the DBA change it dynamically for a running query/session
    • How to do it
      Part of it was already done, others are probably underway. The CPU usage is described above
    • Benefit
      Improve the DBA ability to control the system in order to provide the best performance and highest system availability
     

So, some of these were added by me to the request for enhancements (RFE) site. If you like them, vote for them. Comment as you like of course. And if you have more, please report them in the tool.
Now is the time for the community to stand up and lobby for the features it need. Keep in mind that a request not clearly explained will not have great success. Feel free to discuss it with colleagues, other users in the forums or user group meetings etc.


Versão Portuguesa

Desresponsabilização
Ainda que tenha um termo de desresponsabilização claro na lateral do blog, quero reforçar que este artigo (tal como todos os outros) não representa a posição do meu empregador e não está relacionado com quaisquer planos ou roadmaps. Na verdade, este é provavelmente o artigo em que estou mais próximo dos clientes.

Porque é que estou a escrever isto?
Iniciei a escrita deste artigo ainda antes do lançamento da versão 12.10. Devido a constrangimentos vários mantive o artigo em rascunho, por vários meses. Mas agora é uma boa altura para o publicar. A razão é que a IBM fez algo de extraordinário (já há algum tempo). Criou e disponibilizou uma plataforma onde os clientes podem efetuar pedidos de melhoria nos produtos (sendo que a lista está a crescer) do portfolio IBM. E a boa notícia é que o Informix já lá está.
Devo admitir que tenho grandes expectativas e sou muito entusiasta desta iniciativa, por um número de razões:

• É uma ligação direta entre os clientes e a IBM. Diga à IBM exatamente o que necessita e porquê... Nada de encaminhar os pedidos através de representantes de vendas que têm outras prioridades, ou através de PMRs ou grupos de utilizadores.
• Sendo uma plataforma web é fácil e rápido de usar. Permite inserção de pedidos, votar em pedidos, subscrever alterações, comentar etc.... A lista de funcionalidades é fantástica
• Implica que a IBM esteja disposta a correr alguns riscos: Se um pedido tiver muitos votos, e parecer fácil de implementar, será mais difícil à IBM justificar porque não o faz (convém no entanto não esquecer que os recursos são sempre escassos e limitados)
• É público... novamente, isto é um risco acrescido para a IBM.

E também pode ter algumas desvantagens:

• Se a IBM tomar estes pedidos seriamente (e naturalmente eu acredito e espero que o faça), isto pode interferir com uma abordagem mais planeada e integrada para desenvolvimento dos produtos e disponibilização de funcionalidades
• Existirão muitos pedidos que serão mal explicados ou não serão suficientemente claros, ou que poderão ser alcançados com funcionalidades já existentes. Isto consumirá recursos para filtrar e poderá ofuscar as funcionalidades realmente interessantes (claro que isto é subjetivo...)
• Pode ajudar a expor limitações dos produtos à concorrência (também por isto me parece uma iniciativa corajosa da IBM)

Tendo explicado tudo isto, o link para o site foi adicionado à lista na lateral deste blog. No momento em que estou a escrever este artigo já existem 74 pedidos para Informix. Devo admitir que eu próprio inseri alguns. O sucesso deste processo dependerá em absoluto da participação dos clientes. Reveja os pedidos, selecione os que lhe agradam, vote neles, comente conforme entenda apropriado e crie uma "watch list" de forma a que seja notificado de qualquer alteração. E claro, adicione os seus próprios pedidos se verificar que ainda não estão registados.
Considero este artigo como uma reflexão pública sobre funcionalidades que sinto fazerem falta no Informix. Isto deriva de muitas situações com clientes, mas não é fácil de colocar numa feature request formal, essencialmente porque requereria um business case devidamente fundamentado. Assim isto é a minha visão e desejo pessoal, mas naturalmente influenciado pelos projetos em clientes.
Entretanto, tentei limitar-se ao que me parece ser razoável e de implementação prática "possível" dentro das funcionalidades técnicas. Naturalmente deixei de fora coisas como "desejo que o Informix seja o líder de mercado" ou "gostaria de ver a aplicação XPTO suportar o Informix" etc.
Convém também dizer que dado que não trabalho no desenvolvimento de produto, a minha opinião sobre a dificuldade de implementação de determinadas funcionalidades é mera especulação. Não sou capaz de as quantificar em termos de horas/homem necessárias à sua implementação e suporte. Assim, assuma que isto é mais um brain storm. Se gostar de alguma delas, vote no referido site, faça pressão por elas onde lhe for possível (reuniões do IIUG, customer advisor boards, PMRs, representantes de vendas, durante os EVP - early validation programs - etc.). Tenha presente que a equipa de I&D já terá muito em mente, mas não necessariamente tudo o que queremos ou precisamos. E claro, dado que os recursos são escassos, têm de estabelecer prioridades. Para tal necessitam de receber feedback dos clientes
Para cada funcionalidade tentei dar a minha ideia de como poderia ser implementada e se tal implicaria um grande esforço de desenvolvimentos (com as minhas limitações indicadas acima). Note que a ordem de apresentação é completamente aleatória e não reflete a minha opinião sobre prioridades

A minha lista de desejos pessoais

1. Fazer com que o motor "actualize" automaticamente as distribuições/estatísticas durante/após uma conversão/iupgrade
• Descrição
  Sempre tivemos o processo de upgrade mais fácil do mercado. E a introdução do CONVERSION_GUARD adicionou-lhe um nível de confiança sem precedentes. Mas ainda é necessário correr os UPDATE STATISTICS após a conversão. Fazê-lo para os procedimentos é geralmente muito rápido, mas fazê-lo para todas as tabelas pode levar muito tempo (um DBA experiente conhece várias formas de as acelerar). Gostaria de ver o motor alterar, se necessário, as estatísticas existentes. Isto deveria ser feito apenas quando o formato das mesmas mudar (o que me parece raro). Se houver detalhes recolhidos na nova versão que não eram recolhidos na anterior, então o motor/optimizador deveria saber trabalhar sem eles. Isto permitiria abrir a base de dados ás aplicações muito mais rápido, logo após o fim da conversão (que demora normalmente uns poucos minutos)
• Como fazer
  Honestamente não sei. Na realidade não sei se isto é realmente necessário. Quão frequentemente mudamos o formato das estatísticas/distribuições? Não muito, julgo eu. A ideia desta funcionalidade seria não necessitar da total re-criação das estatísticas/distribuições. Logicamente se a nova versão recolher mais detalhes, o optimizador poderia não ter toda a informação para escolher o melhor plano possível, mas deveria manter o melhor plano da versão anterior
• Benefício
  Reduzir o tempo necessário a fazer uma conversão de forma suportada a apenas alguns minutos. Eu sei... podemos fazer upgrades em clusters MACH-11 sem downtime, mas a forma como isso é feito é complexa (não do ponto de vista do utilizador, mas sim do motor). E nem toda a gente utiliza MACH-11
2. Permitir montar nós secundários de MACH-11 em plataformas heterogéneas
• Descrição
  Atualmente só podemos ter nós HDR/RSS na mesma plataforma que o servidor primário.
  Existem boas razões para isto e provavelmente não as sei todas. Mas algumas destas são:
• Necessitamos de uma imagem "bit por bit" nos nós secundários. Como tal a questão da Endianess das plataformas é relevante
• Necessitamos exatamente da mesma disposição de páginas, portanto a questão do tamanho das páginas pode tornar-se um problema
• Mesmo que a IBM "consertasse" os dois problemas anteriores, ainda haveria problemas potenciais com extensões de terceiros (datablades) que implementem os seus próprios tipos de dados e operações
• Como fazer
  Este é o ponto onde a minha ignorância técnica sobre diversos aspetos da implementação aumenta o risco de escrever algo realmente estúpido. Apesar disso, penso que os dois primeiros problemas acima poderiam ser resolvidos. Em relação à endianess, teríamos de ter isso em conta no envio e receção de informação entre os nós. Penso que isto já é feito em diversos componentes do motor (Enterprise Replication, queries distribuídas etc.). Com isto em mente, penso que seria possível transformar os dados, de forma a que apesar de fisicamente diferente (a ordem dos bytes poderá ser diferente), a imagem "bit por bit" seria alcançada num plano superior, nas camadas baixas de acesso do motor Informix. Claro que isto teria de ser implementado ao nível de todos os componentes usados na gestão do MACH-11 (envio de logical logs, backup/restore, ifxclone, etc.)
  Sobre o problema dos tamanhos de página, isto é uma limitação, mas a realidade é que só existem dois tamanhos: 4KB usado em AIX e Windows, e 2KB usados em todos os outros (que são cada vez menos - HP-UX, Solaris, Linux... ?). Porque não deixar o utilizador definir o tamanho de página "de sistema" ao criar uma instância? Assumindo que o utilizador escolhesse 4KB, seria "portável" em qualquer plataforma. Assim o utilizador teria de considerar isto durante a criação da instância.
  O último problema refere-se a extensões de terceiros. Eu assumiria isto como uma limitação. Se o fornecedor implementasse os mecanismos para tornar isto possível, então ótimo, seria suportado. Caso contrário não seria. O meu ponto é que a maioria dos clientes não utiliza estas extensões de terceiros.
• Benefício
  Esta parte penso que é muito fácil de explicar. Atualmente uma mudança de plataforma requer algum trabalho de export/import, definição de Enterprise Replication ou queries distribuídas para mover os dados. Com esta possibilidade de ter nós HDR/RSS em diferentes plataformas, isto seria alcançado da forma mais fácil (e não há nada mais fácil que estabelecer um nó HDR), e virtualmente sem nenhum donwtime.
3. Permitir upgrades de servidores secundários sem ter de restaurar a partir do primário
• Descrição
  Atualmente a única forma suportada para efetuar um upgrade de um nó secundário (HDR ou RSS) da versão A para a B, é instalar a versão B e restaurar a partir do primário (que entretanto será migrado). Em alguns cenários, quando os servidores estão juntos, isto pode ser realizado num tempo razoável. Mas para servidores geograficamente distantes, isto é um problema bem real. Para ilustrar posso dar um exemplo de um cliente com uma base de dados de 6TB... Isto demora um tempo muito razoável a transferir do local 1 para o local 2. Se para um servidor primário se pode fazer um upgrade em alguns minutos, para um secundário isto pode ser um pesadelo
• Como fazer
  Isto será mais difícil do que vou fazer parecer, mas acredito que seja possível de implementar e traria um grande benefício aos clientes. Antes de mais o primário teria de poder sofrer o upgrade sem perder a noção que é um primário. Assim, durante o upgrade de um servidor primário de um cluster MACH-11, o servidor deveria ser capaz de gravar em filesystem todas as novas imagens das páginas alteradas. Muito semelhante ao que fazemos com a funcionalidade do CONVERSION_GUARD. Mas ao invés de guardar as imagens anteriores, deveríamos gravar as imagens novas.
  Depois  disso, deveríamos arrancar com o servidor secundário na nova versão. Ao iniciar deveria notar que não está a executar a versão anterior. E assim, deveria contactar o servidor primário e "perguntar" se estão na mesma versão. Se sim, deveria perguntar se o primário tem as páginas alteradas gravadas em disco. Se sim, deveria aceitar a transferência dessas páginas e aplicá-las ao storage local. Após isso era como se a conversão tivesse ocorrido também no secundário. Provavelmente seria necessário parar e arrancar de novo, após o que deveria trabalhar normalmente. Penso que o único ponto a ter em conta é que o procedimento não iria funcionar se os nós não estivessem absolutamente sincronizados antes do procedimento. Mas isso faria parte das restrições ou passos mandatórios para efetuar o procedimento.
• Benefício
  Permitir upgrades de nós secundários de clusters MACH-11 sem a necessidade de re-transmitir a imagem completa da instância para as localizações secundárias
4. Expandir o formato do audit trail
• Descrição
  Já efetuei alguns pedidos para introduzir mais informação nos logs de audit. Mas o departamento de I&D tem algumas reservas pois isso quebraria a compatibilidade com possíveis scripts criados pelos clientes. Valorizo esta preocupação, mas penso que isto de facto limita muito a utilidade do sistema de audit 
• Como fazer
  Poderíamos ter algum mecanismo que permitisse ao utilizador definir o que quer que apareça no audit trail. A forma mais fácil seria ter diferentes versões do formato do audit log e deixar que o utilizador escolhesse a versão que quer usar (por omissão seria o formato "clássico"). A mais difícil, mas muito mais flexível, seria deixar o DBA (ou melhor o DBSSO) especificar que informação deveria aparecer para cada menemónica (ou operação auditável). Isto poderia ser definido a partir de um template numa qualquer ferramenta (OAT?). O resultado poderia ser um ficheiro XML com a nova especificação que fosse depois "aplicado" ao motor. Por exemplo, para RDRW, INRW, DLRW e UPRW o utilizador poderia querer ver a linha de dados completa. Eu ficaria satisfeito com qualquer solução intermédia entre estas duas apresentadas.
• Benefícios
  Permitir maior utilidade e promover a aceitação do sub-sistema de audit
5. Os trusted contexts deveriam permitir operações "remotas"
• Descrição
  A introdução da funcionalidade Trusted Context foi interessante, e os 4GL web services deveriam poder tirar proveito disso. Mas quando estamos dentro de um trusted context e mudamos a identidade do utilizador, não podemos executar operações remotas. Existe uma boa razão para isto acontecer: segurança. A nova identidade pode possuir alguns privilégios numa base de dados remota, e nós, como utilizadores locais privilegiados (DBA) poderia-mos criar um trusted context, mudar a identidade, e assim abusar dos privilégios remotos concedidos a esse utilizador. Assim, porque me estou a queixar? Porque no mundo real, muitos clientes criaram várias bases de dados locais (na mesma instância) e as suas aplicações requerem que os utilizadores possam fazer queries distribuídas (locais á instância). Assim, na prática, muitos deles não podem usar trusted contexts 
• Como fazer
  Permitir que um DBSECADM local possa "relaxar" a segurança, permitindo que operações "remotas", que sejam locais à instância possam ser executadas. Isto poderia ser feito através de um parâmetro (global à instância) ou ao nível da base de dados (configurável por SQL)
• Benefício
  Tornar os trusted contexts algo realmente útil e utilizável por clientes que estejam a reaproveitar código 4GL dentro de web services por exemplo. Nestes contextos um dos obstáculos é que o ambiente depende de logging (triggers) dentro da BD que por sua vez só funcionam devidamente com a identidade do utilizador final (o que não é hábito num contexto de web services)
6. Conseguir limpar algumas das caches internas
• Descrição
  Nós conseguimos limpar a statement cache, mas não outras como a distribution cache, a dictionary cache etc. Embora seja verdade que isto não deve ser necessário, já encontrei dois bugs e uma situação não clarificada, onde isto foi necessário. Os bugs foram naturalmente reportados e corrigidos. Mas como workaround teria sido bom conseguir limpar algumas destas caches. 
• Como fazer
  Implementar algumas novas opções no onmode e/ou na SQL API. Poderia simplesmente limpar a cache (mais simples de implementar talvez, mas com maior impacto), ou permitir-nos eliminar uma entrada específica da cache (mais difícil, mas com menor impacto durante a execução da instância)
• Benefício
  Evitar alguns problemas tipicamente causados por bugs. Na ausência desta possibilidade as alternativas são parar a instância ou tentar saturar a cache de forma a que a entrada indesejada seja "empurrada" para fora da cache. Isto é normalmente muito difícil de fazer (embora seja possível)
7. Ser possível limpar a informação em cache do sistema que faz a resolução de nomes e de IPs
• Descrição
  Este problema foi explicado extensivamente num artigo anterior. O sumário do problema é que atualmente não conseguimos fazer alterações na infra-estrutura de DNS sem parar a instância
• Como fazer
  Forçar todos os VPs da classe MSC chamar a função res_init()
• Benefício
  Evitar downtime em caso de alterações na infra-estrutura de DNS
8. Eliminar as restrições do DRDA
• Descrição
  Atualmente temos dois protocolos de comunicação com o Informix. SQLI e DRDA. DRDA é o protocolo usado pelo common client que permite ligações a Informix, DB2 e outras BDs. Infelizmente os clientes DRDA ainda têm algumas limitações como acesso a alguns tipos de dados específicos do Informix etc. Isto pode prevenir a sua adoção genérica pelos clientes. Como muitos produtos IBM usam DRDA para falar com o DB2, isto poderia tornar mais fácil suportar o Informix (no caso dos produtos que ainda não suportam)
• Como fazer
  Isto é uma tarefa complexa. Poderá ser necessário efetuar alterações ao protocolo DRDA. Assim sendo é mais um "desejo"...
• Beneficio
  Tirar proveito de algumas funcionalidades do DRDA que não estão presentes no SQLI. Facilitar que outros produtos IBM suportem o Informix
9. Estender o FORCE_DDL_EXEC a todos os tipos de DDL
• Descrição
  Na versão 11.50 introduzimos uma variável de ambiente que força o fecho de transações que estejam a impedir  um ATTACH/DETACH FRAGMENT. Qualquer DBA num ambiente complexo gritou para que isto existisse para qualquer tipo de DDL (ALTER TABLE, CREATE/DROP TRIGGER etc.)
• Como fazer
  Estender a atual implementação a todos os outros cenários. Na realidade não faço ideia do esforço envolvido e das implicações
• Benefício
  Tornar mais fácil executar DDL num sistema muito ativo. Normalmente os DBAs passam mais tempo a tentar libertar uma tabela do que a aplicar a alteração propriamente dita
10. Scans paralelos em tabelas não fragmentadas
• Descrição
  Apenas lançamos uma thread por partição, porque tradicionalmente assumimos que está localizada num disco e não queremos que as cabeças do disco andem a saltar de um sitio para outro. Mas isto está naturalmente desatualizado devido às alterações sofridas ao nível de storage. O conceito de "disco" já não é o que era (com SANs, stripes etc.).
  Este facto pode tornar os scans desnecessariamente lentos em muitas situações em que de outra forma poderíamos tirar proveito dos mecanismos de paralelismo existentes no motor
• Como fazer
  Poderíamos ligar isto ao IMPLICIT_PDQ, ou criar outra forma de controlo (se o PDQPRIORITY está ativo e a tabela é maior que X etc.). Uma vez calculado o nível correto de paralelismo, uma única partição poderia ser virtualmente considerada como várias e lançada uma scan thread para cada parte
• Benefício
  Queries muito mais rápidas em tabelas não particionadas (se PDQPRIORITY ou IMPLICIT_PDQ estiverem activos)
  
11. Possibilitar que o plano de execução de queries seja obtido em texto simples a partir da própria sessão (usando uma view por exemplo)
• Descrição
  Atualmente necessitamos de escrever o plano de execução em filesystem, ou usar uma ferramenta que suporte o visual explain. Seria bom ter funcionalidade dentro do motor que convertesse o XML gerado pela função EXPLAIN_SQL() em simples texto e que o disponibilizasse numa view.
• Como fazer
  Criei uma prova de conceito e apresentei o resultado na conferência do IIUG em 2010. Dada a falta de tempo e alguns problemas técnicos não consegui prosseguir o trabalho. Mas recentemente trabalhei numa alternativ bastante mais fácil (claro que sou suspeito). Mas ainda assim é um workaround
• Benefício
  Obter um plano de execução tem de ser algo trivial e simples para qualquer utilizador que se conecte à base de dados. Atualmente não é.
12. Poder obter o plano de execução de uma query que já está em execução
• Descrição
  O DBA deveria poder obter de forma rápida e fácil o plano de execução de qualquer query que se encontre em execução. Existe uma ferramenta que de certa forma o permite fazer (xtree), mas o resultado é menos que satisfatório. Alternativamente haveria que ter algumas funcionalidades ativadas (SQL Trace)
• Como fazer
  Implementar algo semelhante ao EXPLAIN_SQL() mas que em vez do texto SQL recebesse um ID de sessão ou outra forma simples de especificar a query em execução que nos interessa. Seria interessante se pudesse estar ligado ao onstat -g pqs (que embora possa ser útil em algumas situações, claramente não foi feito a pensar no DBA - suponho que tenha sido desenhado como ferramenta para o suporte).
• Benefício
  Aumentar a produtividade do DBA. Perceber a razão de lentidão identificada numa sessão tem de ser fácil e simples. Atualmente requer dotes de adivinhação
13. Implementar limites e prioridades para sessões
    • Descrição
      Deveria ser possível limitar vários recursos por sessão (memória, locks, espaço em logical logs, uso de cpu etc.). Alguns destes já estão implementados, outros foram falados e outros ainda parecem relativamente fáceis de fazer. Considere-se o uso de CPU por exemplo... já temos threads e há várias prioridades para as mesmas. Aparentemente bastaria criar um intervalo de prioridades para sessões de utilizador e deixar o DBA geri-las ou limitá-las dinamicamente.
    • Como fazer
      Em parte já estará feito. Outras poderão estar pensadas ou em desenvolvimento.  A utilização de CPU está descrita acima...
    • Benefício
      Aumentar a capacidade do DBA controlar o sistema de forma a providenciar a melhor performance e melhor disponibilidade 
     

Portanto, algumas destas foram adicionadas por mim no site de pedidos de melhoria (RFE). Se gostar delas, vote!. Comente conforme entenda naturalmente. E se tiver mais, por favor reporte-as na ferramenta.
Esta é a altura para a comunidade se unir e motivar e efectuar lobby em prol das funcionalidades que necessita. Não se esqueça que uma explicação clara será fundamental para o sucesso do pedido. Não hesite em discutir estes temas com colegas, outros utilizadores em fóruns ou reuniões de grupos de utilizadores etc.