Friday, July 11, 2014

Version 12.10.xC4 is out! / Saíu a versão 12.10.xC4

This article is written in Englsih and Portuguese (original version here)
Este artigo está escrito em Inglês e Português (versão original aqui)


English version

I'm lagging behind on my objective of a post per week, but as usual... work... But I couldn't let this opportunity pass by. The latest Informix fixpack is out, and the online documentation was updated and the new PDFs are also available. Everything at once as it should be. Apparently this is becoming an habit, and although this would be expected, it didn't always happen, so I must say I'm happy it's happening now.
I'll repeat myself, but being true, I don't see why I shouldn't say it again: Once more we have a fixpack full of features. I honestly think the majority of our customers don't realize the changes the product have been going through... By changes I mean new features, as the "old" ones are still around. But on every fixpack it seems the possible usages and potential users are getting larger and larger. IBM is extending Informix to completely new areas, and I dare to say no other "traditional" RDBMS has seen such a transformation, or better saying adaptation to new requirements and new realities as Informix. As usual I'll pick up the official new feature list and I'll add my comments:

    • Migration
      • Server changes * Enterprise Replication conversion and reversion requirements * JSON compatibility conversion and reversion requirements
        Just a few notes you should consider when doing upgrades/downgrades
      • Easier to import tables with large rows
        A feature that tries to avoid getting too large extents while importing tables with large LVARCHAR columns. With the new option "-D" the extents will be 16KB. If I was asked I'd say I would prefer to let the user to specify the value... Although I understand the issue, 16KB may be too little...
    • Installation
      • Easier installation of 32-bit programs on Windows 64-bit operating systems
        No more need to alter the PATH before installing a 32 bit program in 64 bit Windows
      • Uninstall Informix programs on Windows from the Control Panel
        More convenient
    • Administration
      • Multitenancy in Informix
        Ok... this one deserves a post by itself. You may notice that one of our competitors created a large fuss around something very similar, and that was the big feature of a major release. We introduce it in a discrete fixpack. This fits perfectly in the overall picture of Informix vs other RDBMS. Basically we're build upon the concept of database inside an instance, something we've always supported (as well as in DB2 for that matter). In this fixpack we can now specify a class of CPU VPs and associate it with a "tenant" (CPU resource control), define the number of locks per session on that database, and associate a set of regular and temporary dbspaces for it. No objects from other databases will be allowed on that set of dbspaces, and that database objects can't be created outside of those dbspaces. Temporary dbspaces can however be used by different tenant sessions.
        If you think about it, this looks a simple extension to the database concept. But if you think a bit further you can easily find more things you'd like to do with these new tenants... Some can be "emulated" (I'm thinking about sessions per tenant). Others no, but I'd bet money on the idea that this will be continuously extended in the future
      • Enhancements to OAT
        As usual, new engine features force new functionalists in OAT. Tenant management, in place alter elimination (provided through a task) and a few more
      • Easier removal of outstanding in-place alter operations
        A new SQL Admin API function to eliminate existing in-place alters. This may help avoid more work during the DML operations on tables with these alters. As mentioned before OAT can be used to configure this
      • Limit the size of extendable storage spaces
        Set up a limit for auto expansion of dbspaces/chunks. Useful in any case, but particularly needed for tenants
      • Limit the number of locks for a session
        Finally this undocumented feature becomes officially. Can be set through $ONCONFIG or SET ENVIRONMENT....
      • New default mode for the VP_MEMORY_CACHE_KB configuration parameter
        This parameter specifies the amount of memory cache each CPU VP can use. It was recently extended to have a second option (STATIC, DYNAMIC) do define if it would automatically grow. Now the default changed from DYNAMIC to STATIC
    • Replication
      • Enhancements to the Enterprise Replication apply process and memory pool allocation
        A new CDR_MEM parameter controls the way memory for enterprise replication is allocated. Two new methods are provided for a trade off between memory consumption and performance
      • Replicate hertz and compressed time series data
        ER now allows the replication of both hert (sub-second frequency) and compressed Time Series data. This means these can be used in ER and GRID environments
      • New event alarm for blocked replication transactions
        A new event alarm can now be triggered if transactions are being blocked because a table is in ALTER mode
    • Performance
      • Faster storage optimization
        The compress, uncompress, and repack operations can now be done in parallel by using that option in the commands. It's allowed both for tables and indexes
      • Faster queries with UNION ALL views
        An optimization that tries to avoid the materialization of these type of views. Naturally without materialization, the queries can bu (much) faster
    • Application development
      • Customize the display widths of Unicode private-use characters
        Hopefully most of us won't have to deal with this, but for people using Unicode Private Use Area (PUA), the character base tools now allow the user to specify the display length of each character in that area. In order to do that a user needs to set IFX_PUA_DISPLAY_MAPPING environment variable and create a mapping file in $INFORMIXDIR/gls/etc/pua.map, specifying each character length (1 or 2, 1 being the default)
      • SQL compatibility: LIMIT clause allowed after the Projection clause
        A simple SQL compatibility feature. We could already specify the maximum number of rows in a result set by using the LIMIT option in the projection clause:
        SELECT LIMIT 2 * FROM systables ORDER BY 1
        Now we can specify LIMIT as a clause:
        SELECT * FROM systables ORDER BY 1 LIMIT 2
    • JSON compatibility
      • Enhanced JSON compatibility
        As we've seen in previous fixpacks, the JSON functionality is an hot topic. Some of the features included in this fixpack are:
        • Cursor support so that you can query large volumes of data
        • Text search of string content in collections and tables
        • Geospatial indexes and queries
        • Pipeline aggregation operators
        • The array update modifiers: $each, $slice, $sort
        •  Import and export data directly with the wire listener by using the Informix JSON commands exportCollection and importCollection.
        • Configure a strategy for calculating the size of your database by using the Informix extension to the MongoDB listDatabases command: sizeStrategy option or command.listDatabases.sizeStrategy property. 
        • Customize the behavior of the wire listener by setting new properties. For example:
          • logging,
          • caching
          • timeout
          • memory pools
          • maximum size of documents.
      • Access Informix from REST API clients
        The JSON wire listner can be configured to answer REST API requests. These will use the MongoDB syntax and return JSON documents, but can access MongoDB collections, traditional tables and time series data.
        This makes it easy to interact with the database without installing drivers, just by using these methods.
      • Create a time series with the REST API for the MongoDB API
        The REST API can be used to create a time series. Before you'd have to create it using standard SQL.
      • Basic text searching support for JSON and BSON data
        Basic Text Search datablade was extend to allow indexes over JSON/BSON datatypes. The index can be created and used both through SQL and MongoDB API. BTS supports specific options for JSON documents as it did before for XML for example
      • Access BSON data from JDBC client applications
        The JDBC driver now provides a JSON  object class called IfxBSONObject
      • Quickly export relational tables to BSON or JSON documents
        Easier export of relational tables to BSON/JSON format by using the new function genBSON()
    • Time series
      • Include JSON documents in time series
        A BSON column can be included in a TimeSeries datatype. Ideal for sensors that collect data in BSON format. This can be used through teh REST API
      • Enhancements to the time series Java class library
        More usability for java programmers working with TimeSeries data
    • Security
      • PAM password authentication for DRDA connections
        A specific request from one of "my" customers (A dear customer if I may say so.). It seems weird that we didn't support PAM for DRDA connections. But as you know, PAM is one of my "pet" subjects, so I'd like to explain this. The way PAM is implemented in our engine, we allow the PAM modules to send challenges to the client. The client needs to register a function to handle (answer) these requests. So this means that the database communication protocol must be able to pass through these requests and respective answers. That was not a problem for SQLI which is only used by Informix. But DRDA is used by several databases (Informix, DB2 LUW, DB2 z/OS, DB2i and cloudscape/derby at least. DRDA is also a published standard. So changing it is not trivial. It's not the first time this holds us back, and I'm convinced it won't be the last. The solution was a compromise.... We accept PAM connections in password mode (challenges can't be used). That's not perfect, but it was easy to implement and fitted this customer needs.

    Versão Portuguesa
    Estou a atrasar-me imenso no meu objetivo de ter um artigo por semana, mas como tem sido hábito... trabalho... Mas não podia deixar passar esta oportunidade. O último fixpack do Informix foi disponibilidade há cerca de duas semanas. E a documentação online e os novos PDFs foram disponibilizados ao mesmo tempo. Tudo em simultâneo como deve ser. Aparentemente isto está a tornar-se um hábito, e embora fosse expectável, nem sempre aconteceu. Por isso sinto-me satisfeito que aparentemente tenham finalmente "entrado nos eixos".
    Vou repetir-me, mas sendo verdade não vejo porque o não deva fazer. Mais uma vez temos um fixpack cheio de novidades. Penso que a maioria dos nossos clientes nem se apercebe das mudanças que têm sido introduzidas no produto... E por "mudanças" quero dizer funcionalidades novas, já que as "antigas" continuam lá e de boa saúde. Mas em cada fixpack parece que as potenciais  utilizações e potenciais utilizadores são cada vez mais abrangentes. A IBM está a expandir o Informix para áreas completamente diferentes e novas e atrevo-me a dizer que nenhuma outra base de dados "tradicional" terá visto uma tão grande transformação, ou melhor dizendo, adaptação a novos requisitos e novas realidades como o Informix. Como habitualmente vou pegar na lista de novidades oficial e acrescentar os meus comentários.
    • Migração
      • Mudanças no servidor * Requisitos de conversão de Enterprise Replication * Requisitos de conversão e reversão de compatibilidade JSON
        Apenas algumas notas que devemos ter em conta ao preparar upgrades e downgrades
      • Mais fácil importar tabelas com registos longos
        Uma funcionalidade que tenta evitar obter extents demasiado grandes em tabelas com campos LVARCHAR grandes. Com a nova opção "-D" no dbimport os extnents serão de 16KB. Se me perguntassem, diria que o melhor era a opção permitir indicar o tamanho. Apesar de perceber o problema que está a tentar resolver, diria que 16KB também é demasiado pequeno
    • Instalação
      • Instalação mais fácil de programas de 32 bits em Windows de 64 bits
        Deixa de haver a necessidade de alterar a PATH antes de instalar uma versão de 32 bits num Windows de 64 bits
      • Desinstalação de programas Informix a partir do painel de controlo
        Maior conveniência
    • Administração
      • Multitenancy no Informix
        Ok... esta merece um artigo exclusivo."tenant" em Inglês quer dizer inquilino, ou arrendatário. Mutitenancy é um termo usado em TI para descrever o "alojamento" ou agrupamento de várias entidades sob uma única entidade de gestão e configuração. Poderá ter notado que um dos nossos concorrentes fez um grande alarido em torno de algo semelhante, e foi anunciado como uma grande funcionalidade (ou A grande funcionalidade) de uma versão principal. Nós introduzimos isto num fixpack discreto. Isto encaixa perfeitamente na imagem global do Informix vs outras bases de dados.
        Basicamente estamos a construir sobre o conceito de uma base de dados dentro de uma instância, algo que sempre suportámos (e já agora o DB2 também). Neste fixpack introduzimos algumas capacidades adicionais: Ter uma classe de CPU VPs e associá-la a um tenant (controlo de recurso de CPU), definir o número de locks por sessão nessa base de dados e associar um conjunto de dbspaces só para ela. Objectos de outras bases de dados não serão aceites neste conjunto de dbspaces, e os objectos desta base de dados não podem ser alocados noutros. No entanto dbspaces temporários podem ser partilhados.
        Se pensarmos sobre isto parece uma simples extensão ao que já existia, ou seja o conceito de base de dados. mas se insistirmos no tema, facilmente encontramos coisas que gostaríamos de fazer com estes novos tenants... algumas poderão ser "emuladas" (estou a pensar num limite de sessões por tenant). Outras nem tanto, como seja limitar a memória ou logical logs usados por cada um. Por isso apostaria dinheiro na ideia que isto será um ponto de evolução permanente a partir de agora.
      • Melhorias no OAT
        Como é habitual, novas funcionalidades do motor, implicam novas funcionalidades do OAT. A gestão dos tenants e eliminação de inplace alters pendentes são dois exemplos.
      • Mais fácil remoção de inplace alters
        Uma nova função SQL permite eliminar inplace alters pendentes em tabelas. Um inplace alter será o que resulta de um ALTER TABLE que não tenha refeito a tabela. Ou seja, enquanto houver páginas que fisicamente estão na versão anterior, considera-se uminplace alter pendente. A remoção destas situações pode fazer-se com dummy updates (SET col1 = col1 WHERE 1 = 1). Isto evita que durante UPDATES e DELETEs o motor tenha de converter o formato das páginas que contenham registos alterados.
        Esta nova tarefa facilita a remoção destas situações. Como mencionado anteriormente, o OAT pode ser usado para gerir esta tarefa.
      • Limitar o tamanho dos espaços de alojamento extensíveis.
        Podemos agora definir um limite máximo para os chunks/dbspaces que estejam em auto extend. Bastante útil em qualquer caso, mas faz ainda mais sentido se conjugado com o conceito de tenants
      • Limitar o número de locks  por sessão
        Finalmente esta funcionalidade não documentada torna-se oficial. Pode ser definido no $ONCONFIG ou com a instrução SET ENVIRONMENT
      • Novo valor por omissão do parâmetro VP_MEMORY_CACHE_KB
        Este parâmetro específica a quantidade de cache de memória que cada CPU VP pode usar. Foi recentemente estendida para podermos definir com uma segunda opção (DYNAMIC, STATIC) se seria dinâmica ou estática. O comportamento por omissão agora será STATIC (podendo ser definido como DYNAMIC)
    • Replicação
      • Melhorias no processo de aplicação de dados replicados e na alocação de memória no Enterprise Replication
        Um novo parâmetro CDR_MEM controla a forma como a memória para enterprise replication é alocada. Dois novos métodos fornecem opções que permitem um trade-off entre consumo de recursos e performance.
      • Replicação de TimeSeries comprimidos e do tipo hertz
        O ER permite agora replicar hetrz (frequência sub-segundo) e TimeSeries normais comprimidos.Assim ambos podem ser usados em ambientes ER e GRID
      • Novo evento com alarme para bloqueios em transações replicadas
        Este alarme irá disparar se houver transações bloqueadas devido à colocação de uma tabela em modo ALTER
    • Performance
      • Otimizações de storage mais rápidas
        O compress, uncompress e repack podem agora ser executados em paralelo usando a opção parallel das respetivas funções. Isto aplica-se tanto a tabelas como índices
      • Queries sobre views com UNION ALL mais rápidas
        Uma otimização que tenta evitar a materialização de views deste tipo. Naturalmente sem materialização as queries poderão correr (muito) mais rápido
    • Desenvolvimento de aplicações
      • Configuração do tamanho de apresentação dos caracteres de uso privado do UNICODE
        Em princípio a maioria de nós não terá de se preocupar com isto, mas para quem use  Unicode Private Use Area (PUA), as ferramentas em modo carácter permitem agora a especificação da dimensão de cada um desses caracteres. Para o fazer temos de definir a variável de ambiente IFX_PUA_DISPLAY_MAPPING e criar um ficheiro de mapeamento em $INFORMIXDIR/gls/etc/pua.map, indicando para cada carácter a dimensão de apresentação (1 ou 2, sendo 1 o valor por omissão)
      • Compatibilidade SQL: cláusula LIMIT permitida depois da cláusula de projeção
        Uma funcionalidade de compatibilidade SQL simples. Já há muitos anos que podemos limitar o número de linhas no resultado de uma query usando a opção LIMIT na cláusula de projecção:
        SELECT LIMUT 2 * FROM systables ORDER BY 1
        Agora podemos também usar o LIMIT como cláusula:
        SELECT * FROM systables ORDER BY 1 LIMIT 2
    • Compatibilidade JSON
      • Melhorias na compatibilidade JSON
        Como temos visto em fixpacks anteriores, a funcionalidade JSON tem sido um tópico quente. Algumas das funcionalidades introduzidas agora são:
        • Suporte para cursores de forma a que seja possível tratar grandes quantidades de dados
        • Procura de texto em tabelas e collections
        • Queries e índices Geo-Espaciais
        • Operadores de agregação pipeline
        • Modificadores de update de arrays: $each, $slice, $sort
        • Importação e exportação de dados directamente com o wire listener utilizando os comandos Informix JSON exportCollection e importCollection
        • Configurar uma estratégia para calcular o tamanho da sua base de dados utilizando a estensão Informix ao comando MongoDB listDatabases: opção sizeStrategy ou a propriedade command.listDatabases.sizeStrategy
        • Configurar o wire listener através de novas propriedades. Por exemplo:
          • logging,
          • caching
          • timeout
          • memory pools
          • tamanho máximo dos documentos
      • Aceder ao Informix através de clientes de REST API
        O wire listener para JSON pode ser configurado para responder a pedidos REST API. Estes usarão a sintaxe do MongoDB e retornarão documentos JSON. Mas podem aceder a collections MongoDB. tabelas tradicionais e dados TimeSeries
        Isto torna o acesso à base de dados mais simples para casos onde a instalação de drivers e uso das APIs tradicionais seja mais complicado
      • Criação de um TimeSeries através a REST API, sobre a MongoDB API
        A API REST pode ser usada para criar um TimeSeries. Antes seria necessário criá-lo com SQL podendo depois usá-lo através do JSON wire listener
      • Suporte BTS para dados JSON e BSON
        O Basic Text Search datablade foi estendido para suportar índices sobre dados JSON/BSON. O índice pode ser criado e utilizado tanto via SQL como com MongoDB API. O BTS passa a suportar opções específicas para documentos JSON como já suportava por exemplo para XML
      • Aceder a dados BSON de aplicações cliente JDBC
        O driver JDBC fornece agora uma classe de objeto JSON chamada IfxBSONObject
      • Exportar rapidamente dados de tabelas relacionais para documentos BSON ou JSON
        Através da nova função genBSON() pode exportar-se os dados de tabelas relacionais, convertendo-os para BSON ou JSON
    • Time series
      • Inclusão de documentos JSON em TimeSeries
        Pode incluir-se uma coluna BSON num tipo de dados TimeSeries. Ideal para sensores que recolham ou produzam dados em formato JSON. Isto pode ser usado através da REST API
      • Melhorias na classse TimeSeires da biblioteca de Java
        Maior usabilidade para programadores Java que trabalhem com dados TimeSeries
    • Securança
      • Autenticação por password, usando PAM com DRDA
        Um pedido específico de um dos "meus" clientes (um cliente bastante apreciado se o posso dizer). Pode parecer estranho que não suportássemos PAM em conexões DRDA. Mas como saberão, o PAM é um dos meus temas "de estimação" e por isso gostaria de explicar isto. A forma como o PAM está implementado no nosso motor, permite que os módulos PAM enviem "desafios" aos clientes. O cliente tem de registar uma função ou método para lidar e responder a estes desafios. Ora isto implica que o protocolo de comunicação saiba lidar e preveja o envio destes pedidos e respetivas respostas. Issso não foi um problema para o SQLI, que apenas é usado pelo Informix. Mas o DRDA é usado por várias bases de dados (Informix, DB2 LUW, DB2 z/OS, DB2i e  Cloudscape/Derby pelo menos). DRDA é também um standard público e publicado. Assim, mudar o protocolo não é trivial e envolve processos formais e morosos. Não é a primeira vez que isso nos causa problemas e presumo que não será a última. A solução encontrada foi um compromisso... Aceitamos ligações DRDA com PAM desde que estejam em modo "password" (desafios não podem ser usados. Isto não será o ideal mas terá sido (muito) fácil de implementar e foi ao encontro das necessidades do cliente.

    Thursday, May 01, 2014

    Power8: Linux news / Power8: Novidades Linux

    This article is written in Englsih and Portuguese (original version here)
    Este artigo está escrito em Inglês e Português (versão original aqui)


    English version
    The Informix world should be focused on the IIUG annual conference taking place in Miami. But the world doesn't stop spinning and possible important news for Informix come from other locations and origins.
    Last week IBM announced it's new version of the Power CPU. That's the new Power8, an impressive beast with 12 cores, 8 threads per core etc. But why am I touching this subject on an Informix blog? Because besides this latest evolution that naturally brings much more capacity, IBM have been doing some interesting actions regarding the Power architecture... Sometime ago, IBM opened up the design of this technology and created the OpenPower foundation. This allows other companies to produce chips and be involved in the future of the platform. This companies include heavy hardware users like Google, mobile market giants like Samsung, software (Linux) partners like Canonical (Ubuntu) and chip makers like Nvidia. This effort seems able to generate some interesting results. Among them we have Google showing a Power8 based motherboard on IBM's Impact 2014 conference. There are already partners building Power machines. And some features of the new processor were influenced by this:

    • CAPI - Coherent Accelerator Processor Interface
      It's a feature designed to allow better and tight integration between the CPU and specialized processor units (accelerators) like FPGAs, GPUs etc
    • PowerKVM
      KVM is a kernel based virtualization layer. The Power systems were already able to run Linux LPARs but they need to have IBM's PowerVM underneath (the IBM Hypervisor). Now it's possible to have just the hardware, then PowerKVM and Linux VMs on top. All in an OpenStack compliant system
    • Little Endian Linux
      Endianess has to do with the way long words/words etc. are organized in memory. There are two flavors depending on whether the higher byte/word (most significant) is stored before or after the lower part (least significant). For us, simple users this seems an irrelevant techie thing... and in part it's true. But it's highly important when you think about porting applications and specially data.
      RISC systems (AIX, HP-UX - PA-RISC, Solaris Sparc) etc were created Big-Endian. Linux on Intel is Little-Endian. Linux on Power was Big-Endian.
      With Power8, the OS may decide the mode. And IBM and it's partners are working on Little-Endian Linux for Power.
    The last point is where I wanted to reach.... The implications of this shift are huge. If you check the link above on Google+ where a Google engineer shows the Power8 based motherboard, it says the board was created "to port our software stack to POWER (which turned out to be easier than expected, thanks in part to the liitle-endian support in P8)". But this may have more implications and I'd like to raise one: In the past we've seen one OS (HP-UX) move from one platform (PA-RISC) to another (Itanium). At that time Informix/IBM did something that never repeated itself again: We issued a note stating that customers making this move could back up their PA-RISC systems and restore on Itanium servers. Further more it said that customers could have their primary HDR server on PA-RISC and their HDR secondary servers on Itanium. I suppose we all agree this means or translates into a very smooth transition or migration path. And it was possible because the platform endianess didn't change. For pre-Power8 systems, if you wanted to move an Informix instance from Intel Linux to Power Linux you'd have to export and import. With Power8 I believe this could be possible by simply backup/restore or by means of HDR/RSS setup. Note: This is my personal thought... nothing along these lines was announced and I have no internal knowledge about any plans to do so (neither would I share them before official announcement of course). I'm just mentioning this because I think this could be a very interesting topic for Informix customers to discuss with IBM. And since some of them have joined IIUG's conference I leave it as food for thought.

    Final note

    One of the best things about writing this blog is that it forces me to do some (or sometimes a lot) of research about the topics I'm writing about. In particular I like to see what's happening on the competitors field. This time I ended up on an Oracle blog post about Power8. As you'd expect they don't have nice things to say about this, and that's always interesting reading (as the good things are easy to find on IBM's side). But I feel sad and sorry when there are no good arguments on "the other side". Just to highlight a few examples:
    • This sentence "IBM seems to be re-aligning POWER8 to cover lost ground since it decided to de-invest in x86 entirely, while Oracle has instead adopted the strategy of adding/building value for enterprise environments and adding functionality to enhance customer experience (our software in silicon with SPARC processors, Oracle Solaris enhancements and Engineered Systems as examples)" confuses me... Is the author referring to the "engineered systems" like Exadata which actually are made of "their software", on Intel's hardware?!
    • The author says "IBM delivered only two POWER updates in the last four years". That's more or less the truth if you consider major upgrades which is a normal cycle for hardware. But then it says "Oracle increased investment in SPARC and Oracle Solaris delivering five generations of SPARC processors in four years, and doubling performance with each release". Hmmm... so it's now 10x faster than it was in 2010. There goes Dave House's tweak on Moore's law. And if that's so, why are they loosing market share and using Intel processors on Exadata? At least IBM uses Power CPUs on our flagship "product" Watson!
      Actually Oracle released T3 (September 2010), T4 (September 2011) and T5 (March 2013). T3 and T4 were already on Sun's roadmap.
    • The author points to a roadmap where the next releases are marked for 2015, 2017 and 2019. Roughly every two years... exactly what is criticized about IBM's Power last 4 years. Point taken! :)
    My point regarding the above post is simply that CPU battles have always been a leap frog game. IBM is currently in the lead, Intel will answer, next Sparc (2015) may have something to say and so on... And each vendor will show it's strengths and it's up to the competitors to show possible weaknesses. But if anyone wants to argument, it's better to use good arguments. And that's clearly not the case here. And it's a fact that IBM is doing things differently with the OpenPower foundation and the third party collaboration. Market and time will tell us the results.



    Versão Portuguesa
    O mundo Informix deverá estar focado na conferência anual do IIUG a decorrer em Miami. Mas o mundo não para de girar e podem surgir notícias importantes para o Informix vindas de qualquer origem.
    Na semana passada a IBM anúnciou a nova versão do seu CPU Power. Trata-se de uma "besta" impressionante com 12 núcleos, 8 threads por núcleo etc. Mas porque estou a tocar neste assunto num blog dedicado ao Informix? Porque para além desta última evolução que como é expectável trás muito maior capacidade de processamento, a IBM tem estado a desenvolver outras atividades muito interessantes na área da arquitetura Power... Há algum tempo atrás a IBM abriu o desenho e planos desta tecnologia e criou a  fundação OpenPower. Isto permite a outras empresas produzir chips e envolverem-se na evolução futura da tecnologia. Entre estas empresas encontram-se consumidores de larga escala como a Google, gigantes da área mobile como a Samsung, parceiros de software (Linux) como a Canonical (Ubuntu) bem como fabricantes de chips especializados como a Nvidia. Este esforço parece capaz de gerar resultados interessantes. Entre os quais temos a  Google a demonstrar uma motherboard baseada em Power8 na conferência IBM's Impact 2014. Existem também já  parceiros a construir máquinas Power. Por fim, algumas das novidades do Power8 foram influenciadas por este movimento:
    • CAPI - Coherent Accelerator Processor Interface
      É uma funcionalidade desenhada para permitir a melhor integração entre o CPU e unidades especializadas de processamento (aceleradores) como FPGAs, GPUs etc.
    • PowerKVM
      KVM é uma camada de virtualização baseada no kernel. Os sistemas Power há muito que podem correr Linux nas suas LPARs, mas necessitavam ter o PowerVM da IBM por baixo (o Hypervisor da IBM). Agora é possível ter apenas o hardware, depois o PowerKVM e as VM's Linux por cima. Tudo num sistema conforme com o OpenStac
    • Little Endian Linux
      Endianess diz respeito à forma como as palavras longas ou palavras (64 ou 32 bits) são organizadas na memória. Existem dois métodos, dependendo se o byte ou palavra mais "alto" (mais significativo) é guardado antes ou depois do componente mais baixo (menos significativo). Para nós, simples utilizadores, isto parece um detalhe técnico... e em parte é verdade. Mas isto é extremamente importante quando pensamos em portar aplicações e especialmente dados entre sistemas
      Os sistemas RISC (AIX, HP-UX - PA-RISC, Solaris Sparc) etc foram todos criados como  Big-Endian. Linux em Intel é Little-Endian. Linux em Power era Big-Endian.
      Com o Power8, o OS pode decidir o modo. E a IBM e os seus parceiros têm estado a trabalhar num Linux Little-Endian para Power8
    Este último ponto era onde queria chegar... As implicações desta mudança são imensas. Se consultar
    o link acima no Google+, onde um engenheiro da Google mostra uma motherboard baseada em Power8, ele diz que a placa foi criada (tradução livre) "para portar a nossa pilha de software para o Power8 (o que se revelou mais fácil que o esperado, graças em parte ao suporte Little-Endian do P8)". Mas isto pode ter outras aplicações e gostaria de salientar uma. No passado já vimos uma migração de um sistema operativo (HP-UX) de uma plataforma (PA-RISC) para outra (Itanium). Nessa altura a Informix/IBM fez algo que nunca mais se repetiu: Emitimos uma nota informando que os clientes que seguissem este caminho, poderiam fazer um backup das suas instâncias em PA-RISC e fazer um restore dessas imagens em servidores Itanium. Ainda mais, poderiam ter os seus nós primários em PA-RISC e montar os nós secundários (HDR) em servidores Itanium. Suponho que todos concordamos que isto se traduz numa forma muito tranquila de fazer uma migração de plataforma. Isto foi possível porque o tipo de endianess dos sistemas não mudou. Para sistemas Power anteriores ao Power8, se desejássemos mover uma instância de Linux em Intel para Linux em Power teríamos de exportar e importar os dados. Com o Power8 acredito que tal fosse possível através de um simples backup/restore ou usando o mecanismo de HDR. Há que salientar que isto é apenas a minha opinião... Nada relativo a isto foi anunciado nem eu tenho qualquer conhecimento interno sobre o tema (nem o revelaria antes de um anúncio oficial). Apenas menciono este tema, pois penso que seja um tópico de discussão bastante interessante para a IBM e clientes Informix. E como alguns desses clientes e parceiros estão reunidos na conferência do IIUG parece-me apropriado deixar isto como tópico de discussão.

    Nota final

    Uma das melhores coisas que resultam de escrever este blog é que tal me obriga a fazer alguma (por vezes muita) pesquisa sobre os tópicos que escrevo. Em particular eu gosto de ver o que se vai passando na nossa concorrência. Desta vez acabei neste artigo de um blog da Oracle sobre o Power8. Como seria de esperar, não têm coisas simpáticas a dizer sobre o tema, e isso é sempre uma leitura interessante (já que as coisas boas são fáceis de encontrar do lado da IBM). Mas lamento e sinto-me triste quando não há bons argumentos "do outro lado"... Apenas vou salientar alguns exemplos:
    • Esta frase (tradução livre) "a IBM parece estar a realinhar o Power8 para recuperar o terreno perdido desde que decidiu desinvestir totalmente na plataforma x86, enquanto ao invés a Oracle adotou a estratégia de adcionar/construir valor para ambientes empresariais e adicionar funcionalidades para melhorar a experiência dos clientes (o nosso software com processadores SPARC, melhorias no Oracle Solaris, e "engineered systems" como exemplo)" confunde-me... O autor refere-se a "engineered systems" como o Exadata que na verdade assenta em cima de tecnologia Intel?!
    • O autor diz (tradução livre) "a IBM anunciou apenas duas atualizações aos Power nos últimos quatro anos". Isso é mais ou menos verdade, se considerar-mos atualizações significativas, e é o normal em termos de hardware. Mas depois diz "a Oracle aumentou o investimento em SPARC e Oracle Solaris, tendo introduzido cinco gerações em quatro anos, e duplicando a performance em cada mudança". Hmmm... então no espaço de quatro anos tornou-se 10x mais rápido.... Lá se vai a variante de David House sobre a lei de Moore... e se assim é porque continua a perder quota de mercado e a usar processadores Intel no Exadata? A IBM no nosso "produto" bandeira (Watson) usa a tecnologia Power! Na verdade, como é demonstrado nos próprios slides referidos no mesmo artigo, a Oracle lançou o T3 (Setembro de 2010), o T4 (Setembro de 2011) e o T5 (Março de 2013). O T3 e T4 já estavam no roadmap definido pela SUN
    • O autor aponta um roadmap onde os próximos lançamentos estaõ marcados para 2015, 2017 e 2019. Grosso modo de dois em dois anos... exatamente aquilo que é apontado à IBM como sendo pouco. Entendido!
    O meu ponto, relativamente ao artigo referido, é que as batalhas de CPUs sempre foram como as corridas de rãs. Atualmente a IBM toma a liderança, a Intel irá responder, depois os SPARC (2015) podem ter algo a dizer, e assim por diante.... Cada fornecedor irá mostrar as suas mais-valias, e caberá à concorrência apontar possíveis fraquezas. Mas quem queira argumentar, deverá usar bons argumentos, bem fundamentados e estruturados. E este não é um desses casos. E de facto a IBM está a fazer coisas diferentes com a fundação OpenPower e a colaboração de terceiros. O mercado e o tempo dir-nos-ão os resultados.

    Friday, April 25, 2014

    EXECUTE IMMEDIATE: SQL injection prevention / EXECUTE IMMEDIATE: Prevenção SQL injection

    This article is written in Englsih and Portuguese (original version here)
    Este artigo está escrito em Inglês e Português (versão original aqui)


    English version
    Recently I was requested to implement some stored procedures on a customer site. The request was urgent and I must admit I didn't pay enough attention. The procedures needed to accept some values that would be used inside some SQL statements. Basic best practices mandate that we must check all parameters and in such cases use prepared statements. These principles provide for better interaction with the calling layer and more important, help us avoid a classic and nasty security flaw called SQL injection.
    The idea behind SQL injection is terribly simple and efficient: By supplying specially crafted parameters we explore the developer's mistake of not sanitizing those parameters and blindly use them to construct SQL statements. By doing so we may be able to change the meaning of those statements or eventually terminate them and include our own. A couple of examples:

    1. An authentication page uses the SQL statement:
      SELECT
          COUNT(*)
      FROM
          user_table
      WHERE
          user_name = $USER AND user_pass = '$PASS'
      

      and we supply these arguments:
      'john_doe'
      'dummy'' OR ( user_name = ''john_doe'' )'
      

    2. An online banking uses the SQL statement:
      UPDATE
          balance_account
      SET
          ammount = ammount - $VALUE
      WHERE
          account_number = $SOME_NUMBER
      

      and we supply these arguments:
      - 1000
      our_account_number
      

    Well, after the procedures were created and some basic testing was done I had a bit more time to look at the code and I noticed I used the SQL instruction "EXECUTE IMMEDIATE..." where I was just concatenating some SQL with the provided arguments. Some of them were being slightly checked, but others were not checked at all. I was alarmed and ashamed by that piece of code and I decided to prove it was crappy... I tried to send weird parameters which included a semi-colon and a full statement following it. As an example consider something like:

    CREATE PROCEDURE test_proc(table_name VARCHAR(20))
        EXECUTE IMMEDIATE "DROP TABLE " || table_name
    END PROCEDURE;
    

    And I tried to send "some_table;DROP DATABASE d"

    (consider that some_table is an existent table name and "d" and existing database)
    It raised error

    26058: EXECUTE IMMEDIATE and PREPARE in SPL cannot allow multiple SQL statements
    

    Which was a bit of a surprise. I tried other variations and they all failed.
    The error description is clear. And the manual too:

    http://www-01.ibm.com/support/knowledgecenter/SSGU8G_12.1.0/com.ibm.sqls.doc/ids_sqs_0768.htm?lang=en

    As a security measure or not, EXECUTE IMMEDIATE and PREPARE, inside stored procedures don't allow the execution of more than one instruction. A reason for that can be to avoid this specific type of SQL injection exploitation. So it was a good surprise to see that the good people in R&D have thought about something that I failed to (at my first attempt). This is a good security measure. But don't get too enthusiastic.... Terminating a statement and including another on in a variable or argument is just one of the SQL injection attacks. It will be useless on the two examples above. So be aware and never do the same error I was about to do: Always check your parameters and if possible PREPARE your statements. That's the way to avoid these security issues.
    For the so called "cursory" statements we can use PREPARE, DECLARE, OPEN, FETCH, CLOSE and FREE. For non-cursory statements we need to use EXECUTE IMMEDIATE. In any case, it's essential to validate all inputs!





    Versão Portuguesa
    Recentemente foi-me pedido que implementasse algumas stored procedures num cliente. O pedido era urgente e devo admitir que não prestei a devida atenção. Os procedimentos necessitavam de aceitar alguns valores que seriam depois usados em instruções SQL. As boas práticas mais simples ditam que temos sempre de validar os inputs e sempre que possível usar prepared statements. Estes princípios permitem uma melhor interação com a camada que executa os procedimentos (ou genericamente funções), e mais importante, ajudam-nos a evitar uma falha de segurança bastante má, chamada SQL injection.
    A ideia base do SQL injection é terrivelmente simples mas eficiente: Fornecendo argumentos "construidos", exploramos falhas dos programadores que não validam nem purificam os argumentos que lhes são passados, usando-os cegamente na construção de instruções SQL. Ao fazê-lo podemos alterar o sentido dessas instruções e eventualmente até terminá-las e escrevendo outras imediatamente a seguir. Um par de exemplos:
    1. Uma página de autenticação usa a seguinte instrução:
      SELECT
          COUNT(*)
      FROM
          tabela_utilizadores
      WHERE
          nome_utilizador = $USER AND pass_utilizador = '$PASS'
      

      e fonecemos estes argumentos:
      'john_doe'
      'dummy'' OR ( nome_utilizador = ''john_doe'' )'
      

    2. Uma aplicação de banco online utiliza esta instrução SQL:
      UPDATE
          tabela_contas
      SET
          saldo = saldo - $VALUE
      WHERE
          numero_conta = $UM_NUMERO
      

      e fornecemos estes argumentos:
      - 1000
      our_account_number
      

    Bom, depois de ter criado os procedimentos, e após alguns testes básicos de funcionalidade, tive um pouco mais de tempo para examinar o código e verifiquei que estava a usar a instrução "EXECUTE IMMEDIATE...", e estava apenas a concatenar um pedaço de SQL com os argumentos fornecidos. Alguns tinham algum tipo de validação muito básica, mas outros não eram validados de todo. Fiquei alarmado e envergonhado com algum daquele código e decidi provar a mim mesmo que aquilo não prestava.... Tentei enviar parâmetros compostos de forma específica, incluind um ";" e uma instrução completa em seguida. A título de exemplo considere algo como:

    CREATE PROCEDURE test_proc(table_name VARCHAR(20))
        EXECUTE IMMEDIATE "DROP TABLE " || table_name
    END PROCEDURE;
    
    E tentei usar como argumento "tabela_teste;DROP DATABASE d"

    (considere que "tabela_teste" era o nome de uma tabela existente e que "d" era o nome de uma base de dados também existente)
    Obtive um erro:

    26058: EXECUTE IMMEDIATE and PREPARE in SPL cannot allow multiple SQL statements
    
    Isto foi um pouco surpreendente. Tentei outras variações e todas falharam.
    A descrição do erro parecia clara. E o manual também:

    http://www-01.ibm.com/support/knowledgecenter/SSGU8G_12.1.0/com.ibm.sqls.doc/ids_sqs_0768.htm?lang=en

    Por medida de segurança ou não, o EXECUTE IMMEDIATE e o PREPARE dentro de procedimentos SPL não permitem a execução de mais que uma instrução. Uma razão para tal pode ser evitar este tipo específico de exploração de SQL injection. A ser assim foi uma surpresa agradável que o pessoal de I&D se tenha lembrado de algo que eu me esqueci (na primeira versão). Isto constitui uma boa medida de segurança. Mas não fique demasiado entusiasmado.... Terminar uma instrução e incluir outra é apenas uma das variantes do SQL injection. É inútil nos dois exemplos acima. Portanto esteja atento e nunca cometa o mesmo erro que estive á beira de cometer: verifique sempre os parâmetros e se possível utilize o PREPARE das suas instruções SQL. Essa é ainda a melhor forma de evitar estes problemas.
    Para as instruções baseadas em cursores podemos usar o PREPARE, DECLARE, OPEN, FETCH, CLOSE e FREE. Para instruções que não retornem um conjunto de resultados necessitamos de usar o EXECUTE IMMEDIATE. Em qualquer caso é essencial validar todos os inputs!

    Monday, April 21, 2014

    Informix on Power 7 / Informix em Power 7

    This article is written in Englsih and Portuguese (original version here)
    Este artigo está escrito em Inglês e Português (versão original aqui)


    English version
    IBM has the capability to do things right without anyone knowing about it. A very simple example of this is the publication of a white paper about the use of Informix on Power7 architecture.
    I was aware of the existence of such a document internally, but I didn't noticed it was published.

    You can find it and download it easily (doesn't happen always :) ) here:

    https://www.ibm.com/developerworks/community/wikis/home?lang=en-us#!/wiki/W6461741bf7e8_47d7_89fc_a0a9233f3ca9/page/IBM%20Informix%20on%20POWER7

    The topics covered include:

    • SMT configurations (SMT1, SMT2, SMT4)
    • Dedicated LPAR vs Shared LPAR
    • Virtual Server I/O (VIOS)
    • Memory
    • I/O subsystem
    • Network
    • CPUs
    I would like to see something equivalent for virtualization technologies, specifically VMWare.

    Versão Portuguesa
    A IBM tem a capacidade de fazer coisas boas sem que ninguém saiba. Um exemplo muito simples disto é a publicação de um documento sobre a utilização de Informix em Power 7.
    Tinha conhecimento da existência deste documento internamente, mas não dei porque tivesse sido publicado.

    Pode encontrá-lo e obtê-lo facilmente (nem sempre isso acontece :) ) aqui:

    https://www.ibm.com/developerworks/community/wikis/home?lang=en-us#!/wiki/W6461741bf7e8_47d7_89fc_a0a9233f3ca9/page/IBM%20Informix%20on%20POWER7

    Os tópicos abordados inclúem:
    • Configuração de SMT (SMT1, SMT2, SMT4)
    • LPARs dedicadas vs partilhadas
    • Virtual Server I/O (VIOS)
    • Memória
    • Sub-sistema I/O
    • Rede
    • CPUs
    Gostaria de ver algo equivalente para plataformas de virtualização, em particular VMWare