Yes, I'm still here. And soon so vNext will be / Sim, ainda estou por cá. E em breve a vNext também
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
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)