A return or just a notice about vNext (original version here)
English version
Long time "no see"... I can't really remember about my last post, but apparently it was in 2019, and I only posted two articles during that year. A long time has passed, and the reasons for not posting are the usual ones...: I've been working with other products (although I never stopped working with Informix), lack of time, other priorities etc., etc... That doesn't really matter and this article doesn't necessarily mean I'll be posting frequently in the future... Though I remind I started posting when IBM was about to release version 11.10 (Cheetah). New stuff naturally triggers the will to share some views and (hopefully) some knowledge. And we're getting close to a new major version (currently only known, at least by me, as "vNext"). And a new major version should bring new and interesting stuff... even considering the "continuous delivery" that briefly means that when a feature is ready it will be out of the door in the next fixpack, which naturally means "major" versions may seem to contain very few new things.
Recently my colleague Scott Pickett shared some insights about vNext in an IIUG webcast. And the list of announced changes pushed me write this article... The list seems long and nice. And the focus seems to be the expansion or removal of some internal limits, which were last changed in V10 (March 2005).
This is a slide of the presentation and shows some of the limits that should change. One not listed here, but under consideration is the maximum row size. From the above I'd like to highlight and comment on some:
- Larger partitions
Many customers are hitting the current limit. Note however that if they're hitting this limit, you should probably partition your data - More rows per page
Extremely important because it means we can use larger page sizes without the issue of wasting space in each page - Timestamp moving to 8-byte
An end to the issue with incremental backups? Yes, probably, but just this change won't solve the slowness of incremental backups (because we need to read all the pages to identify the ones we should send to the backup)
Besides the focus on limits, development is also concentrating efforts on customer requests, entered through the Aha website. Among these I'd like to highlight a few:
- Obtain the query plan of a running query
I've requested this in the website before Aha. I wrote several articles about this (including an hack to try to show this should be easy to implement). Need I say more about this? Only that it comes too late... but apparently it will appear in a proper way, because it can be obtained with "onstat" command and through a pseudo table (although with a limit of 32K) - Storing large objects in a file system
This will allow Smart Blobs to be stored in a filesystem, external to the database system. I have some mixed feelings about this. I'd say that because the filesystem is not a transactional system, this may open up possibilities to create some inconsistency between the filesystem and the metadata in the database. I hope that in the future there will be ways to check this. But on the other hand, this functionality will allow much easier maintenance and backup of this type of data. Whenever I see customers using Smart Blobs I remember a specific customer where most of their database is composed of Smart Blobs. And they have serious issues with backups for example (the backup infra-structure is not properly sized for the load this implies). Filesystem backups can be much more efficient because they already support incremental archiving. Obviously the downside is that a full restore will probably mean dual restore sessions (database and filesystem). But we need more info before deciding if this is a good thing or not. I think it clearly opens up possibilities to solve specific issues at very large databases where most of the data is composed of Smart BLOBs - CDC log capture from secondary
CDC means change data capture, and Informix provides a way (API) for external applications to capture changes that are then replicated by them to external systems. Incidentally IBM has a product called InfoSphere Change Data Capture, and I've been doing a lot of work with it lately. The ability to attach these 3rd party (including IBM other products in this classification) to the secondary servers is a feature I can imagine a lot of customers using in order to lower the load on the primary servers. - CREATE/ALTER DATABASE - implicit transactions, owner qualified names unique, cursors for update
This seems to be adding ANSI features like proper object owner nomenclature and automatic start of transactions to non-ANSI mode databases. Seems interesting for increased compatibility with other RDBMs, but I'd say some of them (implicit transactions) would require application changes. But, being new options that's good. We should like options!
Something I'd like to see in non-ANSI databases that we already have in ANSI databases is the raising of an error if we try to INSERT/UPDATE CHAR like data that doesn't fit in the field length (currently we silently truncate it)
- Add SID to audit log
I also requested this many years ago in the old RFE site. In fact I recall some email exchanges with Jonathan Leffler (old timers will recognize the name for sure) about this. It won't solve all the issues, but it will allow an audit log analysis to reconstruct a sequence of actions, which currently we can't understand, because the logs only contain the client PID (process ID) and for Java applications that's always -1, meaning we see a bunch of audit entries but can't really correlate them. - Allow indexes to be made invisible to queries
This allows a DBA to "test" the removal of an index (applications and query optimizer will stop seeing this index) while still keeping and maintaining the index... if the result is bad we can just "reactivate" it, without having to rebuild the index which can be painful - Updated Global Language Support (GLS) (Phase 1)
Not much information about this (current, standard code sets are mentioned). But I'd like to emphasize that it mentions "Phase 1") - Informix should not need ROOT permissions
It's stated that the default installation will be "non-root" method. This looks nice from a security perspective but it raises some issues (for authentication for example). I'll have to wait and see the implications of this feature. But it will be important, assuming the default installation method will change - Incremental Archives
Not new right? Yes. We already have them (at least in theory), but high activity sites may not be able to use them due to the short timestamp we're using. And this limit will apparently change (see slide above). However, to have proper incremental archives we would need something else: A quick method to identify changed pages without having to read all the instances pages (current method). And I see no mention to this issue - SET SCHEMA: Informix should support switching 'schemas' in the middle of a transaction
Currently there's a limitation on the statement "SET SESSION AUTHORIZATION" where it can't be used in the middle of a transaction. Apparently there are plans to remove this limitation. However, I think a bit of context is required here. This statement could be very useful to allow applications using application server to "propagate" the final user identity to the database, while using a pool of connections opened with a single "application user". This is very important when old systems that rely on the user identity for logging/auditing purposes on the database (using triggers for example) start to get used also by application servers which normally authenticate with a single user and open a series of connections that will be shared by different "application sessions".
Now... this new feature may facilitate this, but what I've seen in several customers preventing this usage is that during a "session" that changed the authorization with SET SESSION AUTHORIZATION we CANNOT do remote SQL. And by "remote" I mean any action in another database on the same instance. And many customers have several databases that are used by a single application using this type of "remote SQL". So that limitation should also be removed, otherwise I think the usefulness of the feature will be very limited
I did not cover all the new mentioned features. For a full list, please check the webcast. I've only focused on the ones I think are more important or the ones I had comments about. Your preferences may vary of course, so the best is to check the source of information.
The last question is of course "When?". As usual the dates may vary... and there is no compromise about an ETA, but let's assume for now it should be this year. And we're about half way through...
Let's hope I'm able to continue covering these new features here! Glad to be "back", even if it was just this time.
Versão Portuguesa
Há quanto tempo... Na realidade não me lembro quando fiz a última publicação, mas aparentemente foi em 2019, e só publiquei duas vezes nesse ano. Muito tempo passou e as razões para não publicar são as habituais...: Tenho estado a trabalhar com outros produtos (ainda que nunca tenha deixado de trabalhar com Informix), falta de tempo, outras prioridades etc.,
etc... Isso agora não interessa, e este artigo não quer necessariamente dizer que irei publicar com frequência no futuro... Embora me recorde que comecei a publicar quando a IBM estava para lançar a V11.10 (Cheetah).
Novidades naturalmente inspiram a partilha de perspectivas e (espero) algum conhecimento. E estamos a chegar perto de uma nova versão (actualmente apenas conhecida por "vNext", pelo menos por mim). E uma nova versão deverá trazer uma série de coisas interessantes... mesmo no contexto do "continuous delivery" que sumariamente significa que assim que uma funcionalidade está pronta será lançada no próximo fixpack, o que naturalmente "esvazia" um pouco os lançamentos de novas versões.
Recentemente o meu colega Scott Pickett partilhou algumas novidades sobre a vNext num webcast do IIUG. E a lista de modificaões anunciadas fez-me escrever este artigo... a lista parece longa e interessante. E o foco parece ser no aumento ou remoção de alguns limites internos, que foram revistos pela última vez na V10 (Março de 2005)
Isto é um diapositivo dessa apresentação e mostra alguns dos limites que deverão ser alterados. Um que não está aqui listado mas que está a ser analisado é o tamanho máximo de uma linha. Dos apresentados acima gostaria de salientar e comentar alguns:
- Partições maiores
Muitos clientes estão a atingir este limite. Note-se no entanto que se atingimos este limite, provavelmente já deveríamos ter particionado os dados - Mais registos por página
Extremamente importante porque significa que poderemos usar tamanhos de página maiores sem receio de desperdiçar espaço em cada página - Alteração do Timestamp para 8 bytes
Um fim para o problema dos backups incrementais? Sim, provavelmente, mas esta alteração por si só não resolverá o tema da performance deste tipo de backups (porque temos de ler todas as páginas para identificar aquelas que devem ser colocadas no backup)
Para além do foco nos limites, o desenvolvimento está também a concentrar esforços nos pedidos dos clientes, introduzidos no site Aha . Nestes, gostaria de salientar alguns:
- Obter o plano de execução de uma query em execução
Pedi isto no site anterior ao Aha. Escrevi vários artigos sobre isto (incluindo um truque para tentar mostrar que a implementação não deveria ser difícil). Preciso de dizer algo mais sobre o tema? Apenas que vem tarde... Mas aparentemente vai aparecer da forma correta, pois poderá ser obtido através de uma opção do comando "onstat" e também por via de uma view (ainda que limitado a 32K) - Guardar Smart Large Objects num filesystem
Isto permitirá que os Smart BLOBs sejam guardados como ficheiros num filesystem externo ao sistema de base de dados. Tenho sentimentos contraditórios em relação a isto. Dado que os sistemas de ficheiros não são sistemas transaccionais, isto poderá abrir a possibilidade de haver inconsistências entre o conteúdo do sistema de ficheiros e a metadata na base de dados. Espero que o futuro traga ferramentas para verificar isto. Mas por outro lado, esta funcionalidade irá permitir uma gestão e backups deste tipo de dados muito mais fácil. Sempre que vejo clientes a usarem Smart BLOBs lembro-me de um determinado cliente em que a esmagadora maioria do espaço são Smart BLOBs. E dos problemas que daí advêm, nomeadamente em termos de backup (a infra-estrutura de backups está claramente sub-dimensionada para a quantidade de dados que têm). Os backups de filesystem podem ser muito mais eficientes porque já permitem de forma muito simples backups incrementais. A desvantagem deste tipo de solução é que um possível restore implicará sessões de restore ao nível da base de dados e do filesystem. Mas precisamos de mais informação para decidir se isto será uma boa funcionalidade ou não. Penso que isto claramente abre possibilidades para resolução de problemas em bases de dados muito grandes onde a maioria dos dados são Smart BLOBs. - Captura de logs para CDC a partir de um secundário
CDC significa "change data capture" e o Informix fornece uma forma (API) para que aplicações externas capturem alterações que depois serão replicadas para sistemas externos. A IBM tem um produto chamado InfoSphere Change Data Capture, e eu tenho feito bastante trabalho com ele nos últimos tempos. A capacidade de ligar estes produtos de terceiros (estou a incluir produtos externos ao Informix, ainda que da IBM) aos nós secundários é uma funcionalidade que imagino ver muitos clientes a quererem usar para baixar a carga sobre o servidor primário - CREATE/ALTER DATABASE - transações implícitas, nomes com qualificação de owner únicos, cursores para update
Parece ser a adição de funcionalidades ANSI, como nomenclatura de objectos correctamente qualificadas com identificação de owner e início automático de transações, a bases de dados criadas sem modo ANSI. Parece interessante para compatibilidade com outros RDBMS, mas diria que algumas (transações implícitas) implicarão alterações de aplicações. Mas sendo uma opção nova parece bom. Devemos apreciar o facto de termos opções!
Uma característica de base de dados ANSI que gostaria de ver em bases de dados não-ANSI é a ocorrência de um erro sempre que tentamos inserir ou alterar dados do tipo CHAR que não caibam na definição do campo. Actualmente truncamos os dados sem dar erro.
- Adicionar o SID ao log de audit
Também pedi isto há muitos anos no antigo site de RFE (Requests For Enhancement). Inclusivamente lembro-me de uma troca de emails com o Jonathan Leffler (os mais antigos certamente reconhecem o nome) acerca deste tema. Não resolverá todos os problemas, mas permitirá reconstituir uma sequência de acções através da análise dos logs de audit. Actualmente tal não é possível porque o único elo de ligação entre as acções é o PID (ID de processo) do cliente, mas em aplicações Java isto aparece sempre como -1, o que impede a correlação entre as acções que vemos nos logs de audit - Permitir que os índices fiquem invisíveis às queries
Isto permite que um DBA possa testar a remoção de um índice (as aplicações e o optimizador de queries deixarão de os ver) fazendo no entanto com que o índice continue a ser actualizado... Se o resultado for mau, podemos simplesmente reverter sem ter de reconstruir o índice que pode ser uma operação muito pesada - Actualização Global Language Support (GLS) (fase 1)
Não há muita informação sobre isto (menção ao uso de códigos de caracteres standardizados e actualizados). Mas gostaria de salientar que está marcado como "fase 1" - O Informix não deverá precisar de permissões de ROOT
É indicado que a instalação padrão passará a ser "sem root". Isto soa bem do ponto de vista da segurança, mas levanta algumas questões (relativas à autenticação por exemplo). Terei de esperar para ver as implicações desta funcionalidade. Mas considerando que o método padrão mudará será algo importante no futuro - Arquivos incrementais
Nada de novo, certo? Sim. Já existem arquivos incrementais, mas instalações com muita actividade podem estar impedidas de os usar, devido ao pouco tamanho do timestamp com que as páginas são marcadas. E isto será mudado (ver diapositivo acima). No entanto, para termos arquivos incrementais optimizados necessitaríamos de outra coisa: Uma forma rápida de identificar as páginas alteradas (desde o último arquivo) sem ter de ler todas as páginas da instância (método actual). E não vi nenhuma referência a este tema - SET SCHEMA: Informix deveria suportar a troca de 'schemas' no decorrer de uma transação
Actualmente há uma limitação na instrução "SET SESSION AUTHORIZATION" que é a mesma não poder ser usada no meio de uma transação. Aparentemente há planos para remover esta limitação. Mas penso que temos de adicionar aqui algum contexto. Esta instrução pode ser muito útil para permitir que aplicações que usam servidores aplicacionais possam "propagar" a identidade do utilizador final (usada entre o cliente e o servidor aplicacional) até à base de dados, quando a ligação à base de dados é feita com uma pool de ligações aberta com um único utilizador aplicacional. Isto é muito importante em sistemas antigos que dependem da identidade do utilizador para efeitos de logging/auditing na base de dados (usando triggers por exemplo), quando começam a ser usados também por aplicações através de servidores aplicacionais, que abrem ligações à base de dados com um utilizador aplicacional.
Ora... esta funcionalidade pode facilitar isso, mas o que vi em vários clientes que impede este uso é que durante uma "sessão" onde tenha sido usada a instrução "SET SESSION AUTHORIZATION" não podemos executar nenhum tipo de "SQL remoto". E por "remoto" quero dizer qualquer acção noutra base de dados ainda que na mesma instância. E muitos clientes têm várias bases de dados que são usadas por uma única aplicação com este tipo de "SQL remoto". Portanto esta limitação deveria ser removida, caso contrário penso que a funcionalidade continuará a estar limitada.
Não cobri todas as funcionalidades mencionadas na sessão referida. Para uma lista completa por favor assista ao webcast. Apenas foquei as que me parecem mais importantes ou sobre as quais tinha comentários a fazer. As preferências de cada um variam naturalmente, pelo que o melhor é consultar a fonte da informação.
A última questão é "Quando?". Como é hábito, as datas podem variar.... e não existe qualquer compromisso quanto a uma possível data de disponibilização, mas podemos assumir que será este ano. E o ano já vai a meio...
Vamos esperar que eu continue a cobrir estas novas funcionalidades. Estou contente por estar "de volta" mesmo que não haja muita continuidade nestes artigos.
Posts
