Tuesday, October 11, 2016

ixtempuse news / novidades sobre o ixtempuse

Some slight changes in ixtempuse script (original version here: http://informix-technology.blogspot.com/2016/10/ixtempuse-news-novidades-sobre-o.html)

English version
A few weeks ago I announced the availability of a new script that allows a DBA to see which sessions are consuming temporary space. After release I received some feedback about it's use which triggered some changes and /or thoughts.  Specifically users faced these two issues:

  1. The script didn't work in version 9.40
    After some investigation I noticed I was using a column in one of the sysmaster view which didn't exist in version 9.40. I managed to use a workaround, but after that I've found another issue when I tried to retrieve the page size of a dbspace. I was getting it from a column on the sysdbstab view, but because we only introduced the ability to have chunks of different pagesizes in V10 the column didn't exist in previous versions
  2. The script didn't run when it was most needed: when the temporary dbspaces are full
    At first glance this seemed a very short sight on the way I created the script. In fact I need to create a temporary table and those will be created in the temporary dbspaces. If they're full I may have a problem. But further investigation showed the engine moves those table creation to other dbspaces. The issue seems to be the execution of the script on secondary servers when the temporary dbspaces are full.
To solve issue 1) above I did some changes in the script. It tries to adapt to the version currently being used. The solution for problem 2) is more complex. It's not feasible to do the script without the temporary tables. It could be possible but it would be very difficult. As already explained, the script should run on primary/standard servers because the engine will shift the temporary tables location to the dbspace holding a database or to rootdbs (in the case of the script it will be rootdbs as it's connecting to sysmaster). For secondary servers, this shift is not possible. The only workaround I can think of requires a "trick" and some planning in advance: A DBA can create a very small temporary dbspace (10-50MB is more than enough) without adding it to the list of dbspaces in DBSPACETEMP. And then export DBSPACETEMP=newtinydbspace to run the script. Because we're not adding it to the DBSPACETEMP $ONCONFIG parameter, it will not be used for the session's work and will be reserved for the script usage when needed. It's not a pretty solution, but it's the only I can think about currently.

Meanwhile I received some interesting feedback and I think we can see a solution for the base problem in future versions. We have to wait and see, but I really hope this script will become nearly useless in the future, which as weird as it sounds is actually a very good thing!

The new version of the script is available in the same place:

Versão Portuguesa
Há algumas semanas atrás anunciei a disponibilidade de um script que permite ao DBA verificar quais as sessões que estão a consumir espaço temporário. Depois disso recebi feedback sobre a sua utilização que suscitaram algumas alterações e análises. Especificamente os utilizadores depararam-se com os dois problemas seguintes::
  1. O script não funcionava na versão 9.40
    Na verdade o script não era suposto funcionar, dado que não foi testado em versões sem suporte. Mas após alguma investigação verifiquei que estava a utilizar uma coluna numa das views da sysmaster. Consegui recorrer a outra forma de efetuar a query mas rapidamente bati noutra coluna que também não existia (estava a ver o tamanho da página de um dbspace numa coluna da view sysdbstab, mas como só introduzimos a possibilidade de ter dbspaces com diferentes tamanhos de página na V10, a coluna só então foi introduzida)
  2. O script não corria quando era mais necessário: quando os dbspaces temporários estavam cheios
    à primeira vista parecia um erro básico na forma como construí o script. Na verdade eu necessito de criar tabelas temporárias e estas serão criadas nos temporários. Se já estão cheios é natural que tenha um problema. Mas depois de investigar, verifiquei que o motor muda a localização das tabelas temporárias para um dbspace normal (o da BD ou o rootdbs). O problema afinal trata-se da execução do script em servidores secundários quando os temporários estão cheios.
Para resolver o problema 1) acima, efetuei algumas alterações no script. Agora tenta adaptar-se à versão de motor que está a ser usada. A solução para o problema 2) é mais complexa. Não é viável fazer o script sem criar as tabelas temporárias. Não seria impossível mas seria bastante difícil. Como explicado atrás o script correrá em motores primários/standard pois o motor cria as tabelas temporárias para o dbspace onde a BD foi criada ou para o rootdbs (neste caso será sempre o rootdbs uma vez que estamos a ligar-nos à sysmaster). Mas nos servidores secundários esta adaptação não é possível. A única solução que me ocorre requer planeamento antecipado para implementar um "truque". Um DBA poderá criar  um dbspace temporário muito pequeno (10-50MB será mais que suficiente) não o adicionando à lista definida no parâmetro DBSPACETEMP no $ONCONFIG. E depois para a execução do script exportar a variável DBSPACETEMP=dbspacetemp_pequeno. Como não o adicionamos ao DBSPACETEMP do motor ele não será usado pelo trabalho normal das sessões e estará reservado para utilização do script quando necessário. Não é uma solução bonita, mas é a única que me parece possível de momento.

Entretanto recebi algum feedback interessante, e penso que poderemos ter uma solução definitiva para o problema base (saber as sessões que estão a consumir espaço temporário). Teremos de esperar para ver, mas espero que realmente este script venha a ser inútil no futuro, o que por muito estranho que pareça, é uma coisa muito boa!

A nova versão do script está disponível no mesmo endereço:

Saturday, October 01, 2016

Cloud replay and more... / Apresentação da cloud e mais...

Review the Informix on cloud presentation, announcement, tips and something more (original version here: http://informix-technology.blogspot.com/2016/09/cloud-replay-and-more-apresentacao-da.html)

English version
Last Monday we had the webcast about the new Informix on Cloud offering. For those who couldn't attend the live conference, the webcast replay is available in the following address:

The official announcement can be found here (EMEA):

The slides for from the presentation were uploaded to slideshare.net:

The actual service can be accessed here:

 The main characteristics of this offering are:

  • Users will have full (root) access and will be responsible for managing a Linux server (CentOS)
  • Informix advanced Enterprise Edition will be installed and Informix Warehouse Accelerator will be included (not configured)
  • There will be 4 sizes of server with different resources (CPU, Memory, DISK, Network)
  • The server will be available through public Interner access. It can be configured by the users to participate in a VPN for example
  • No managing, monitoring or backing up services are currently offered. This can change in the future, but currently the customer has total freedom to implement whatever best fits their requirements
  • It works as if a server was rented in the cloud and the customer used their Informix licenses but of course that's not necessary as customers are charged on a monthly base that includes everything, including product support
The lack of backup services is relative issue. IBM and other vendors have several methods for storage use in the cloud. Some solutions could be considered.
Actually something that I personally find interesting is the possibility to run backups to the cloud. Currently Informix already supports it for Amazon S3. But the implementation seems a bit too simplistic. Something I've been trying as an exercise seems more interesting and with a bit more potential: Our backup tool, onbar, interacts with the Storage managers using a standard and open protocol called XBSA. It's possible to create a XBSA library that sends the objects to the cloud. Just a few hours ago I managed to make my first restore  from a previous backup sent to the cloud. It took me less than a week of free time to create this. It currently has less than 1000 lines of codes written by me. And yes, it's incomplete, doesn't have proper error handling or debugging, doesn't manage metadata or an object catalog etc. But it clearly shows it could be a path to cloud storage use for database backups. Additionally some cloud services (like IBM's Bluemix Object Storage) use a standard called SWIFT which makes it relatively easy to support several cloud providers if the library can be configured externally. Hopefully in the future I'll be able to write an article dedicated to this proof of concept.

Versão Portuguesa
Na passada segunda-feira tivemos o webcast sobre a nova oferta de Informix na nuvem. Para quem não pôde assistir em direto, a gravação da conferência está disponível no seguinte endereço:

O anúncio oficial pode ser encontrado em (EMEA):

Os slides da apresentação foram carregados no slideshare.net:

O serviço propriamente dito pode ser encontrado aqui:

As características principais do serviço são:
  • Os utilizadores terão acesso total (root), e serão responsáveis pela gestão de um servidor Linux  (CentOS)
  • A edição Advanced Enterprise do Informix estará instalada e o Informix Warehouse Accelerator estará disponível para configuração
  • Existem 4 tamanhos para os servidores com diferentes recursos (CPU, memória, disco e rede)
  • O servidor estará acessível pela Internet pública. Poderá ser configurado pelos utilizadores para fazer parte de uma VPN
  • Não são oferecidos serviços de gestão, monitorização ou backup. Estes aspectos poderão vir a ser alterados no futuro, mas neste momento os clientes têm total liberdade para implementar o que quer que seja que complete o que é oferecido agora, conforme as suas necessidades
  • Funciona como se o cliente alugasse um servidor na nuvem e usasse as suas prórpias licenças, embora isso não seja obviamente necessário visto que o serviço é facturado numa base mensal que inclúi a utilização e o suporte do produto
A falta de um serviço de backup é um problema relativo. Tanto a IBM como outros fornecedores têm disponíveis vários métodos de utilização de armazenamento na nuvem. Poderão ser consideradas algumas soluções.
Na verdade, algo que eu pessoalmente acho interessante é a possibilidade de executar backups para a nuvem. O Informix já disponibiliza essa funcionalidade para o serviço S3 da Amazon. Mas a implementação parece um pouco simplista ou limitada (usa o ontape). Algo que tenho estado a testar como exercício parece-me mais interessante e com mais potencial. A nossa ferramenta de backup, o onbar, interage com os storage managers utilizando um protocolo aberto e standards chamado XBSA. É possível criar uma biblioteca XBSA que envie os objetos para a nuvem. Há apenas algumas horas atrás consegui fazer o primeiro restore a partir de um backup para a nuvem. Levei menos de uma semana de ocupação de tempos livres a criar isto. Neste momento tem menos de 1000 linhas de código escrito por mim. E sim, não tem gestão de erros adequada, ou debugging, não gere metadata nem possuí um catálogo de objetos etc. Mas serve para mostrar claramente que este poderia ser um caminho para integração de backups com a nuvem. Por acréscimo, alguns dos serviços de armazenamento na nuvem (como o Object Storage no IBM Bluemix) utilizam um standard chamado  SWIFT . o que tornaria mais fácil suportar vários serviços desde que a biblioteca pudesse ser configurada externamente. Espero no futuro conseguir fazer um artigo dedicado apenas a este tema