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

Versão Portuguesa

Normalmente começo com a versão Inglesa, mas desta vez tinha naturalmente de começar com a versão Portuguesa. E como já terão reparado o título do artigo está igual em ambas as linguas. O que quer dizer BRIUG? Simples, Brazilian Informix Users Group. E pronto, está o artigo acabado... Não. Ainda não.... Falta dizer que foi criado o grupo Brasileiro de utilizadores de Informix, já tem um website ( http://www.briug.org/ ) e que quem está de momento a dar a cara e o trabalho pelo mesmo é o Miguel Carbone, bem conhecido na comunidade, entre outras coisas porque faz parte do board of directors do International Informix Users Group (IIUG) e o César Martins, autor do blog sobre Informix em http://www.imartins.com.br/informix/
Naturalmente o grupo vai contar com o apoio e colaboração de outras caras conhecidas da comunidade no Brasil e não só. Estou a recordar-me do Vagner Pontes, do Alexandre Marini (muito activo na mailing list do IIUG), do Pedro Henriques.... Temo esquecer-me de alguém.
Tive o privilegio de conhecer pessoalmente algumas destas pessoas durante a conferência anual do IIUG e o que posso dizer é que estou confiante que o assunto está bem entregue.

Do lado de cá do Atlântico vão os votos de muito sucesso, e muito contentamento por ver uma organização deste tipo num País que fala Português. Espero que apesar da distância também nós em Portugal possamos usufruir de algumas iniciativas que o novo grupo venha a desenvolver. E naturalmente quando for necessário uma maõzinha cá estaremos para o que for possível.

English Version:

I usually start by the English version, but this time I had to change. If you noticed, the article title is the same in English and Portuguese... So what is BRIUG? It means Brazilian Informix Users Group... I probably could end the article here, since it's easy to guess what happened, but I must write a few more words... So the Brazilian Informix Users are starting a new user group, and they already have a website ( http://www.briug.org/ ), and for now the people behind it are Miguel Carbone, a well known guy in the community (member of the International Informix Users Group - IIUG - board of directors) and César Martins, author of the Informix blog at http://www.imartins.com.br/informix/.
Naturally the group counts on the support and colaboration of other well known faces of the Brazilian Informix community like Vagner Pontes, Alexandre Marini (very active in the IIUG mailing list), Pedro Henriques.... I'm afraid I'll forget someone...
I had the pleasure of meeting some of these guys during the IIUG annual meeting and I'm convinced that the matter is in good hands.

From this side of the Atlantic ocean, I send my wishes of great success and I'm very happy to see the birth of an organization like this in a Portuguese speaking country.
I hope that despite the distance we in Portugal can take advantage of some of the initiatives that the new group develop in the future. Ans obviously, when you need an helping hand, we're here to do whatever is possible.

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

English Version:

I hope that you had the chance to listen to the latest Chat with the Labs web conference. The topic was really interesting, specially if you're running Informix 7.31, 9.4 or 10. As you should know all these versions are out of support (v10 will be by the end of September). In this call, IBM announced (or re-announced) three options for support of these versions:

1. Upgrade Bridge
   
   • This is just for 7.31
   • Has costs
   • Requires active subscription and support (S&S)
   • Client must have plans for upgrade
   • Can't be sold by partners
   • Doesn't provide R&D access or new fixes development
   • Provides severity 1 critical responses (systems down)
     
2. Continuing Support (Pilot)
   
   • This is for version 9.4 and v10
   • Is included in active subscription and support (S&S)
   • Can be sold by partners, since it's included in S&S
   • Doesn't provide R&D access or new fixes development
   • Provides severity 1 critical responses (systems down)
   • Will end on September 2011 (1 year duration)
     
3. Service extension
   
   • This can be acquired for any unsupported version
   • Has costs
   • Requires active subscription and support (S&S)
   • Can't be sold by partners
   • Provides access to R&D and new fixes development
   • Provides severity 1 critical response (systems down)

So, what does it all mean? Well, it really depends on your current version and your future plans:

• For 7.31 (bridge) means that if you want to migrate, IBM will support you during the time it takes, and can also help you do the upgrade (separate cost). Note that you need to have upgrade plans.
  If you hit a new bug (one that has no fix for 7.31 or that is unknown), you're stuck with it. If you have a system down situation you will get help.
• For versions 9.40 and 10, it means that you'll have one more year of support, included in the regular maintenance fee. Note that again, if you hit a new bug (either really new, or one that has no fix in versions 9.40 or 10) you'll have to live with it
  The good news is that you just need active maintenance (S&S)
• For any version, if you really need access to new fixes (new bugs, or bugs to which there was no fixpack available with the fix), you can request the service extension. Note that this has charges besides the normal S&S cost.

So, the Continuing Support (Pilot) offer means you gained one more year to plan and do an upgrade, while keeping the ability of asking for help in case something goes wrong. Is this good? I believe the answer is yes if you're running one of those versions. But I personally have mixed feelings regarding this. Let's see:

1. Ending support of a product version is always risky, since you may cause customer dissatisfaction
2. Ending support of a product version can lead the customer to consider alternatives from competitors (If I have to migrate, why don't I choose another software....?)
   
3. Keeping endless support for a product is negative for the software supplier for a number of (good) reasons:
   
   • It costs money (resources, source code maintenance, some bugs can be fixed in one way in newer versions, but have to be dealt with differently in older versions)
   • It keeps your customers away from new features and improved product uses
   • Increases the chances that customers favor the competition, because many times they compare the old version of a product from X with a newer version of a product from Y
4. Having old product versions is bad for customers because:
   
   • Increases exposure to old bugs and security issues
   • Limits the ability to move to more recent platforms (hardware and operating systems)
   • Decreases your team members motivation (typically people like to work with new features, and they feel happy to learn new stuff)
5. Upgrades are good for software suppliers and partners because:
   
   • Typically they are drivers for new sales of products and services
   • They are opportunities to get involved with the customers
   • They are opportunities to transfer knowledge and improve customer satisfaction and awareness
   • They can be drivers to new opportunities (cross sell anyone?)
6. Upgrades are good for customers because:
   
   • They have the chance to improve product use
   • They are able to use new features
   • They can move to newer, better and cheaper platforms
   • They can gain new knowledge
7. Upgrades can bin risky because you may face new problems, bugs or human errors
   

All this are advantages and disadvantages to use current software versions. I tried to be absolutely honest and objective (you can judge that and add or emphasize some of the points above). But in general, I'm in favor of keeping up to date with the current versions. Obviously you need to be careful, and stability has to be a value to preserve. But keeping yourself in software versions that are out of support or that will be out of support in a near future is no way to go. Do your upgrades, and do them well. I honestly suggest to everyone that is using 9.4 or 10 to take this new opportunity, and plan your upgrades in the next year. Each environment is different, but I've been very happy with latests 11.50 fixpacks.

So, please, check the web conference files (slides and audio - when available), if you have questions check the contact details, and then plan, plan, plan, test, test, test and upgrade!
I truly believe you'll be very happy with the improvements that IBM have been putting into IDS (and if you want to learn more about the future, check the Panther beta program)



Versão Portuguesa:

Espero que tenha tido oportunidade de assistir à última conferência web da série Chat with the Labs. O tópico foi verdadeiramente interessante, especialmente de estiver a utilizar o Informix 7.31, 9.40 ou 10. Como deve saber, estas versões estão sem suporte (a versão 10 ficará no final de Setembro próximo).
Nesta apresentação a IBM anunciou (ou re-anunciou) três opções para suporte destas versões:

1. Upgrade Bridge
   
   • Apenas para a versão 7.31
     
   • Tem custos
     
   • Necessita de subscrição e suporte activa (S&S)
   • Cliente tem de possuir plano de upgrade
     
   • Não pode ser vendido por parceiros
     
   • Não permite acesso ao desenvolvimento nem a novas correcções
   • Disponibiliza suporte a problemas de severidade 1 (sistemas parados)
     
2. Continuing Support (Pilot)
   
   • Disponível para as versões 9.40 e 10
     
   • Está incluinda na manutenção (subscrição e suporte - S&S)
   • Pode ser vendida por parceiros pois está incluída na manutenção
     
   • Não permite acesso ao desenvolvimento nem a novas correcções
     
   • Disponibiliza suporte a problemas de severidade 1 (sistemas parados)
   • Termina em Setembro de 2011 (duração de um ano)
     
3. Extensão de serviço ou suporte extendido
   
   • Pode ser adquirido para qualquer versão já sem suporte
   • Tem custos
     
   • Necessita de manutenção (subscrição e suporte - S&S)
   • Não pode ser vendido por parceiros
   • Não permite acesso ao desenvolvimento nem a novas correcções
   • Disponibiliza suporte a problemas de severidade 1 (sistemas parados)

Portanto, o que é que tudo isto significa? Bem, depende da sua versão actual e dos seus planos para o futuro:

• Para a 7.31 (bridge) significa que se quiser migrar, a IBM irá fornecer suporte durante o tempo que demorar, e pode até ajudar na migração (custos separados). Note-se que terá de ter planos de upgrade
  Se encontrar um novo bug, (um que não tenha correcção na linha 7.31 ou que seja desconhecido) não lhe será dada solução. Se tiver uma situação de sistema parado ser-lhe-á prestada ajuda.
  
• Para as versões 9.40 e 10 (Continuing Support Pilot) significa que terá mais um ano de suporte, incluído na prestação de manutenção regular. Note-se novamente que se encontrar um novo bug (seja realmente novo, ou um para o qual não exista nenhum fixpack nas versões 9.40 ou 10 que inclúa a correcção) terá de viver com o mesmo
  A boa (excelente?) notícia é que só precisa de ter a manutenção (S&S) activa
• Para qualquer versão, se quer mesmo ter acesso a todas as possibilidades do suporte (incluindo novos fixes) pode contratar a extensão de suporte. Note-se que isto tem custos adicionais ao custo normal de manutenção

Assim, a oferta Continuing Support Pilot significa que ganhou mais um ano para planear e efectuar o upgrade, mantendo entretanto a possibilidade de pedir ajuda caso alguma coisa corra mal. Isto é bom? Penso que a resposta é sim, mas tenho sentimentos contraditórios e pessoais sobre o assunto:

1. Terminar o suporte a uma versão de um produto é sempre um risco, pois pode causar insatisfação dos clientes
2. Terminar o suporte a uma versão de um produto pode levar um cliente a considerar alternativas da concorrência ( se sou obrigado a migrar, porque não hei-de escolher outro software?)
   
3. Manter o suporte por tempo indeterminado ou muito longo é negativo para o fornecedor de software por várias (boas?) razões:
   
   • Custa dinheiro (recursos, manutenção do código fonte, alguns bugs podem ser corrigidos de uma maneira nas versões correntes, mas terem de ser corrigidos de maneira diferente em versões mais antigas)
   • Leva os clientes a não utilizarem novas funcionalidades e não tirarem o melhor partido do que o produto (actual) permite
   • Aumenta as hipóteses de os clientes favorecerem a concorrência, porque muitas vezes compara-se uma versão antiga do produto X com uma versão actual do produto Y
4. Manter versões antigas de produtos é mau para os clientes porque:
   
   • Aumenta a exposição a bugs antigos e falhas de segurança
   • Limita a possibilidade de migração para plataformas mais actuais (hardware e sistema operativo)
   • Aumenta a desmotivação nas equipas de TI (tipicamente as pessoas gostam de trabalhar com as novas funcionalidades e ficam satisfeitas por adquirir novos e mais actuais conhecimentos
5. Migrações de versões podem ser boas para os fornecedores de software e seus parceiros porque:
   
   • Tipicamente são pretexto para novas vendas de produtos e serviços
   • Providenciam oportunidades de criar e manter um maior envolvimento com os clientes
   • São oportunidades para haver transferência de conhecimento e melhorar a satisfação e reconhecimento dos clientes
   • Podem ser pretexto para novas oportunidades noutras áreas de negócio (cross sell)
6. Migrações de versões são boas para os clientes porque:
   
   • São uma oportunidade de melhorar a utilização e exploração dos produtos
   • Permitem o uso das novas funcionalidades
     
   • Permitem migrar para plataformas mais recentes, melhores e mais económicas
   • Permitem adquirir novos conhecimentos
     
7. Migrações de versões acarretam riscos porque se pode encontrar novos problems, bugs ou erros humanos
   

Tudo isto são vantagens e desvantagens de se manter em versões actualizadas do software. Tentei ser absolutamente honesto e objectivo (pode julgar por si, adicionar e relativizar a importância dos vários pontos). Mas em geral, sou a favor de nos mantermos em versões correntes. Naturalmente temos de ter cuidados, e a estabilidade dos ambientes deve ser um valor a preservar. Mas deixar-se cair em versões sem suporte, ou que irão ficar sem suporte num futuro próximo, não é um caminho correcto. Faça os seus upgrades e faça-os bem. Honestamente, sugiro a todos os utilizadores que estejam em versões 9.40 ou 10 que aproveitem esta oportunidade e planeiem as migrações durante o próximo ano. Cada ambiente é um caso específico, mas tenho tinho muito boas experiências com os últimos fixpacks da versão 11.50

Assim, por favor, consulte os ficheiros da conferência web (slides e áudio - quando disponível), se tiver questões consulte os contactos incluídos, e planeie, planeie, planeie, teste, teste, teste e migre!
Julgo sinceramente que ficará bastante satisfeito com as melhorias que a IBM tem incluído no Informix (e se quiser saber mais sobre o futuro veja o programa beta da versão Panther)

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

English Version:

A new draft Redbook was announce by IBM through RSS feeds. It's called IBM Informix Developer's Handbook and it covers lots of aspects of Informix application development and several client technologies (ESQL/C, Java, ODBC, OleDB, PHP, .NET, Hibernate, Ruby...).

I took the opportunity to include some direct RSS feed on the right side of the blog. You can check it for new APARs, announcements etc.


Portuguese Version:

Um novo Redbook, ainda em versão "rascunho" foi anunciado pela IBM através dos feeds RSS. O título é "IBM Informix Developer's Handbook e cobre muitos aspectos do desenvolvimento de aplicações em Informix, e várias tecnologias cliente (ESQL/C, Java, ODBC, OleDB, PHP, .NET, Hibernate, Ruby...).

Aproveitei a oportunidade de inserir alguns feeds RSS no lado direito do blog. Pode utilizá-los para consultar novos APARs, anúncios etc.

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

English version:

I keep working with OAT and the database scheduler and It keeps causing me a very good impression. The fact is that we can really get a structured way to deal with typical issues. The example I'll put here in this article is trivial, and every serious DBA has dealt with it. So, in a sense it doesn't bring anything new. Why the trouble? Because it serves as a very nice example on how things can fit together. During this article I'll show you how to take advantage of some components that you probably already use (alarmprogram and OAT) to build a robust, simple, configurable and also important, elegant space usage monitoring.

I'm sure you probably already have a script to monitor your space usage, so you may be thinking how will I convince you to dump it and use this. Let's see what are the usual issues with that kind of scripts:

1. Typically they're launched by cron. Strangely or not, some customers are restricting the usage of cron. Hopefully this is not your case.
2. Typically the scripts have the mechanism to send alarms inside them. If you need to change anything (email addresses, phone or page numbers), you may have to change several scripts
3. Most of the times the scripts don't have "memory". Meaning for example, they'll keep sending alarms forever. In some cases this maybe useless and annoying.
   
4. Since the scripts don't have "memory", they will not "clear" the alarm if the problem is solved
5. The scripts typically will not send info to OAT. And OAT is elegant and easy to use
6. Typically, different dbspaces in different instances will have acceptable usage thresholds different from each other. This means the scripts need to be more complex to allow customization

I think I could get a few more issues, but the above 6 will be enough. So, my value proposition is to create a mechanism that will solve all the issues above, and that also have some other advantages:

• You can use is as a skeleton to build other monitoring tasks
  
• It's all configurable within the database

As mentioned above we'll need several components:

1. A fully functional ALARMPROGRAM script
   You should already have this, but some more customization will need to be implemented (a few lines)
2. Open Admin Tool up and running
3. Database scheduler active
4. A procedure to call the ALARMPROGRAM script
   I took a look at a recent article from Andrew Ford about auto-extending dbspaces. He also has an example of a procedure to do this.

So, let's begin:

ALARMPROGRAM script changes


You should create a new class for the event generated by this monitoring task. I noticed Andrew recommends adding two classes (101 and 102 in his example), but I prefer to add just one and leave the decision to send email or paging/sms to the other ALARMPROGRAM parameter, the "severity". In fact I typically use a customized ALARMPROGRAM script where I can define that all events with a certain severity will send a short message and with lower will just send an email, or otherwise define a set of classes that send emails or sms independently of the severity

In any case configure and test your ALARMPROGRAM to receive another class and act accordingly to your needs. The advantage of using an ALARMPROGRAM script is that it becomes the only place where you'll need to change email addresses, pager or SMS numbers etc. Once configured it will work perfectly for you, and be re-usable for any kind of monitoring.

Open Admin Tool up and running

As you'll see, this task will generate alerts in the OAT screen. So you'll have something to show to your management. Typically they like to see some fancy graphics... You'll also be able to change the schedule and configuration of the task (including the thresholds). More on this later, as I have one complain about OAT :)

Database scheduler active

As already mentioned, this monitoring tool is implemented as a task in the database scheduler (introduced in version 11). So this is a requirement.

A procedure to call the ALARMPROGRAM script

As mentioned before, we'll need a procedure to call the ALARMPROGRAM script. This procedure will basically receive the parameters, construct a command and make a SYSTEM() call. The path of the ALARPROGRAM script will be queried from the sysmaster database. So if you ever want to change your script location you don't have to worry about this procedure. It will automatically adapt. The code for this procedure can be found in Listing 1 at the end of the article.
This procedure will be called in several places inside our monitoring task.


The task itself: Description and setup

The free space monitoring task is implemented as a stored procedure. You can find it in Listing 2 below. Let's check it nearly line by line.

• Lines 1 and 2 are just the DROP/CREATE instructions. Notice that the procedure takes two arguments that are really great and helpful as we'll see later:
  task_id is the id in the ph_task table. It's unique for each task and allows us to cross reference several other tables in sysadmin
  v_id is the execution number of this task. It will change (increment) each time this task is executed
• The next lines, up to 19, are just variable definitions. I won't explain them since they'll appear in several comments below
• Lines 20 to 25 refer to debugging instructions. Just uncomment the lines 23 and 24 to get a trace of the task execution in a file created in your /tmp directory (obviously this can be changed)
• Lines 29 to 31 are very important. The values defined are the last resort used by the task if all the other configuration parameters aren't in place. The defaults defined are:
  default yellow threshold (90): This will represent the percentage of use for each dbspace, above which an alarm of severity 3 will be raised
  default red threshold (95): This will represent the percentage of use for each dbspace, above which an alarm of severity 4 will be raised
  number of alarms (3): This will represent the number of alarms to send. A number of 0 will mean it will keep sending alarms until the situation is solved.
  
  As we shall see next, these values can be overridden by values configured in the task configuration, and the red/yellow threshold can be configured by dbspace. The above values will only be used if the other more specific configuration items are not setup. And of course, you can change these values in the code, so that they meet your environment.
• Line 33 is very important since it defines the ALARMPROGRAM class number for lack of space in one dbspace. You should adjust these to the value you added to your ALARMPROGRAM. I use values above 900 for my "personal" extensions so that they won't match classes added to ALARMPROGRAM by IBM in the future (we'll never know how many will be added, but 900 seems a reasonable gap...)
• Lines 35 to 93. Here we will try to get the defaults that were configured for the above values. These defaults are configuration items for the task. Unfortunately, current OAT versions don't allow us to use the GUI to setup these initial values. We have to create them using SQL. After that they can be changed using OAT's GUI.... I'd like to see the wizard for a new task creation to include the configuration of any task configuration items.... But it isn't there at this moment (version 2.28...). So we need to insert them via SQL. How to do it: These values are kept in the ph_threshold table, which has the following fields:
  name: This is the parameter name. In our case we have the following: DEFAULT NUM ALARMS, DBSPACE YELLOW DEFAULT, DBSPACE RED DEFAULT and then we can insert any in the forms DBSPACE YELLOW dbspace_name and DBSPACE RED dbspace_name. I think the names are self explanatory. The idea is that if you want to create red/yellow thresholds for specific dbspaces you'll have to insert the DBSPACE RED/YELLOW dbspace_name parameters in the ph_thresholds table. If there isn't a specific value for a certain dbspace it will use the value specified in the DBSPACE RED/YELLOW DEFAULT parameter. If these are also not defined, it will use the values defined in lines 29 to 31.
  task_name: the name of the task from the ph_task table. This value needs to match whatever name we give to the task and that's the one we will use to create the entry in the scheduler. For the purpose of this article I'll use IXMon Check Space. You can use whatever you want, as long as you're consistent.
  value: the value of the threshold. This will be the value to be used by the task. In our case, the DBSPACE RED/YELLOW * parameters will use percentage values (1-100)
  value_type: the data type of the threshold (STRING or NUMERIC). In our case we'll use NUMERIC. From some investigation I noticed that we can use NUMERIC(x,y) for non integer values. I didn't test it, but it should work in case it makes sense for you.
  description: a description of what the threshold does. This will be visible in the OAT's GUI if later you want to change the values using the GUI.
  
  So, to give you some examples, I'll just show the instructions used to create the values that are also specified in the code (number of alarms, red and yellow default thresholds). I'll use the same values:
  
  

  
  INSERT INTO ph_threshold ( name, task_name, value, value_type, description)
  VALUES ( 'DEFAULT NUM ALARMS', 'IXMon Check Space', '3', 'NUMERIC', 'Number of alarms to send');
  INSERT INTO ph_threshold ( name, task_name, value, value_type, description)
  VALUES ( 'DBSPACE YELLOW DEFAULT', 'IXMon Check Space', '90', 'NUMERIC', 'Generic yellow threshiold. It will be applied to any dbspace lacking a specific threshold');
  INSERT INTO ph_threshold ( name, task_name, value, value_type, description)
  VALUES ( 'DBSPACE RED DEFAULT', 'IXMon Check Space', '95', 'NUMERIC',  'Generic red threshiold. It will be applied to any dbspace lacking a  specific threshold');
  

  
  
  And for example, if you have a dbspace called llogs_dbs, dedicated to logical logs which is nearly full and which doesn't make too much sense to monitor you could add:
  
  

  
  INSERT INTO ph_threshold ( name, task_name, value, value_type, description)
  VALUES ( 'DEFAULT YELLOW llogs_dbs', 'IXMon Check Space', '100', 'NUMERIC', 'Make llogs_dbs pass all tests....');
  INSERT INTO ph_threshold ( name, task_name, value, value_type, description)
  VALUES ( 'DEFAULT RED llogs_dbs', 'IXMon Check Space', '100', 'NUMERIC', 'Make llogs_dbs pass all tests....');
  

  
  
  
• Line 97 creates a FOREACH loop. It's based on the query in the next lines which will check the used space in every dbspace in the system
• Lines 98 to 111. This is the dbspace usage query. Some parts of it might not be necessary, but I took the query from another script... Don't worry, it should work. It gives the number of the pages and the number of free pages in all the dbspace chunks grouped together.
  Notice that the task is based on usage percentage. It could be improved to handle other types of parameters, like allocated GB, or free GB etc. For now I kept it simple....
• Lines 114 to 153 are used just to try to find specific thresholds for the dbspace we're processing. If they're not found in the ph_threshold table the generic defaults will be used.
• Lines 154 to 172. Here we calculate the used space percentage and check it against the red and yellow thresholds. If we're beyond any of these values we'll define an alert color and the alert message. If we're below the yellow threshold we leave the color as NULL.
• Lines 175 to 200. If our current dbspace usage is below the yellow threshold we look for an alert in the ph_alert table for this specific dbspace with state equal to "NEW". If we find one we update it, changing it's state to "ADDRESSED". This can happen if after an alarm was generated someone drops a table for example. In this case I'm not calling the ALARMPROGRAM, but it could make sense to call it with a message like "Previous alarm for dbspace_name is canceled because it's now below the defined thresholds"
• From 204 till the end, we have exceeded one of the thresholds.... So... First we query ph_alert to see if we have an alarm for this dbspace in the state "NEW". If we don't (223 - 239) we insert it and call the ALARMPROGRAM using the procedure above. If we already have an alarm we check if it's the same color. If it's not (244 - 252), we update two fields:
  alert_task_seq: we do this to reset the alarm counter
  alert_color: we update the color code of the alarm (for usage in OAT's GUI. Note that at this time we may have a RED alert with an YELLOW message text. I choose to do this, to show that there was a change between the current and previous situation. If the alarm has the same color than we check the field alert_task_seq and compare it with our task execution number (given as a parameter to the procedure) and decide, based on the configured number of alarms if we should call ALARMPROGRAM or not
  

So, finally, how do we schedule the task? Well you can do it by using OAT's GUI or if you want you can insert it directly into the ph_task table:

INSERT INTO ph_task
(
tk_id, tk_name, tk_description, tk_type, tk_dbs,
tk_execute, tk_start_time, tk_frequency,
k_monday, tk_tuesday, tk_wednesday, tk_thursday,
tk_friday, tk_saturday, tk_sunday,
tk_group, tk_enable, tk_priority
)
VALUES
(
0, 'IXMon Check Space', 'Check dbspace free space', 'TASK', 'sysadmin',
'ixmon_check_space', '00:00:00', '0 00:30:00',
't', 't', 't', 't', 't', 't', 't',
'USER','t',0
)

UPDATE [ 20 Aug 2010]:
I missed and IF block wrapping the UPDATE to move the existing alarm to the state ADDRESSED (lines 195-200). Like it was, it would try the update even if we didn't find an alert... This was not very serious, but it you want to call ALARMPROGRAM when the alert conditions clear up, then you need this IF or it will send alarms for every dbspace that is below the thresholds.... Sorry about this mess... So I added the IF on line 194 and the END IF on line 201.

Versão Portuguesa:

Conitnuo a trabalhar com o Open Admin Tool (OAT) e o scheduler de tarefas da base de dados e continuo a ficar bem impressionado com ambos. A verdade é que nos permitem uma abordagem estruturada na gestão de questões típicas. O exemplo que vou deixar neste artigo refere-se a um assunto trivial e qualquer DBA já se deparou com o mesmo. Neste sentido não trás nada de novo. Assim, porquê o trabalho? Porque serve como excelente exemplo de como as coisas se podem encaixar. Ao longo deste artico tentarei mostrar como tirar proveito de alguns componentes que provavelmente já utiliza nas suas instâncias (ALARMPROGRAM e OAT) para construir um mecanismo de monitorização de espaço utilizado que se pretende robusto, simples, configurável e igualmente importante, elegante.

Tenho a certeza que provavelmente já terá um script para monitorizar este aspecto, pelo que poderá estar a pensar como é que o vou convencer a desistir do mesmo e utilizar este (ou algo construído com base neste). Vejamos quais são os problemas habituais destes sripts:

1. Normalmente são lançados pelo cron. Estranhamente ou não, alguns clientes estão a restringir a utilização do cron. Com sorte este não será o seu caso.
2. Muitas vezes os scripts têm mecanismos para enviar alarmes dentro deles. Se necessitar de mudar alguma coisa (endereços de email, números de telefone ou pagers) poderá ter de mudar vários scripts.
3. Na maioria dos casos os scripts não têm "memória". Isto quererá dizer, por exemplo, que continuarão a enviar alarmes sempre (enquanto o problema se mantiver). Em algumas situações isto pode ser inútil e irritante.
   
4. Como os scripts não têm "memória" eles não irão "limpar" um alarme caso se verifique que o problema se resolveu.
5. Em principio os scripts não enviam informação ao OAT. E o OAT é elegante e fácil de utilizar.
6. Tradicionalmente, diferentes dbspaces em diferentes instâncias terão valores de ocupação aceitável diferentes uns dos outros. Isto obriga a maior complexidade dos scripts para permitir a customização.

Provavelmente conseguiria referir mais alguns problemas, mas os 6 acima deverão ser suficientes. Assim, a minha proposta de valor é criar um mecanismo que resolva todos os problemas acima, mas que traga também algumas outras vantagens:

• Possa ser utilizado como esqueleto para outras operações de monitorização
• Seja configurável exclusivamente dentro da própria base de dados

Como referi anteriormente iremos necessitar de vários componentes:

1. Um script de ALARPROGRAM completamente funcional
   Já deverá ter isto, mas serão necessárias algumas alterações (poucas linhas)
2. Open Admin Tool a funcionar
   
3. O scheduler da base de dados activo
   
4. Um procedimento ou função para chamar o script ALARMPROGRAM
   Li recentement um artigo do Andre Ford sobre como auto-estender os dbspaces. Nesse mesmo artigo também há um exemplo de um procedimento para efectuar isto

Comecemos então:

Alterações no script ALARMPROGRAM


Deverá criar uma nova classe para o evento gerado por esta tarefa de monitorização. Notei que o Andrew Ford indica a criação de duas classes (101 e 102 no exemplo dele), uma para enviar emails e outra para gerar SMS/paging, mas eu prefiro criar só uma e deixar a decisão de enviar email ou um pager/SMS baseada no outro parâmetro do ALARMPROGRAM, a severidade.
Na verdade, eu habitualmente utilizo uma versão alterada do ALARMPROGRAM onde eu posso definir que todos os eventos com uma dada severidade enviam um SMS e abaixo disso apenas enviam um email, ou alternativamente definir um conjunto de classes que enviam sempre ou emails ou SMS conforme a gravidade.

Em qualquer caso, configure e teste o seu script de ALARMPROGRAM para receber uma nova classe e agir em conformidade com as suas necessidades. A vantagem de utilizar o script de ALARMPROGRAM é que isto faz com que este seja o único sitío que terá de mexer caso necessite de alterar algum email ou endereço de paging ou número de SMS. Uma vez configurado irá trabalhar perfeitamente para si e será re-utilizável para qualquer tarefa de monitorização.

Open Admin Tool a funcionar

Como se verá mais adiante esta tarefa irá gerar alertas na consola do OAT. Assim terá alguma coisa para mostrar à sua chefia. Habitualmente gostam de ver gráficos agradáveis à vista.... Para além disso, e do ponto de vista prático, o OAT facilitará o agendamento e configuração da tarefa (incluindo os seus parâmetros). Falarei disto mais adiante, até porque tenho uma queixa relativamente ao OAT :)

O scheduler da base de dados activo

Como já foi referido, esta ferramenta de monitorização será implementada como uma tarefa no scheduler da base de dados (introduzido na versão 11). Portanto isto é um requisito directo.

Um procedimento ou função para chamar o script ALARMPROGRAM

Um dos requisitos, se queremos integrar a tarefa com o script de ALARMPROGRAM é ter um procedimento que possa chamar o referido script. Este procedimento irá basicamente receber parâmetros (semelhantes aos do ALARMPROGRAM), e construir um comando de sistema operativo que será depois executado com uma chamada à instrução SYSTEM(). O caminho do ALARMPROGRAM será obtido dinamicamente na base de dados sysmaster. Desta forma não terá de alterar o procedimento, caso necessite de alterar a localização do script no sistema de ficheiros. O código para este procedimento pode ser encontrado na Listagem 1) no final deste artigo. Este procedimento irá ser chamado em vários pontos da nossa tarefa


A tarefa propriamente dita: Descrição e instalação

A tarefa de monitorização é implementada como um procedimento em linguagem SPL. O código da mesma pode ser obtido na listagem 2 no final deste artigo. Vamos analisá-lo quase linha a linha.

• Linhas 1 e 2 são apenas as instruções de DROP/CREATE. Repare-se que o procedimento recebe dois argumentos que são realmente uma grande ajuda, como veremos mais tarde:
  task_id é o id na tabela ph_task. É único para cada tareda e permite-nos referenciar outras tabelas na base de dados sysadmin que sustenta o scheduler e muitas funcionaliades do OAT
  v_id é o número da execução desta tarefa. Irá mudar (incrementalmente) cada vez que a tarefa é executada
• As linhas seguintes, até à 19 são definições de variáveis. Não as irei explicar isoladamente pois serão referidas nos comentários abaixo
• Linhas 20 a 25 referem-se a instruçoes de debug. Remova os comentários das linhas 23 e 24 para obter um trace da execução do procedimento, criado em /tmp (a localização pode obviamente ser mudada)
• As linhas 29 a 31 são muito importantes. Os valores nelas definidos são o último recurso utilizado pelo procedimento se todos os outros parâmetros de configuração não forem definidos. Os valores aqui definidos por omissão são:
  default yellow threshold (90): Isto representa a percentagem de utilização de um qualquer dbspace, acima do qual será emitido um alerta amarelo (severidade 3 no ALARMPROGRAM)
  default red threshold (95): Isto representa a percentagem de utilização de um qualquer dbspace, acima do qual será emitido um alerta vermelho (severidade 4 no ALARMPROGRAM)
  number of alarms (3): Isto representa o número de alarmes a enviar. Um valor de zero sinaliza que devem ser enviados alarmes até que a situação seja resolvida
  
  Como veremos a seguir, estes valores podem ser sobrepostos por valores atribuídos a parâmetros de configuração da tarefa, e os limites vermelho e amarelo podem ser definidos por dbspace.
  Os valores acima só serão utilizados se os outros, mais específicos não forem definidos. E claro que estes valores podem ser alterados no código do procedimento antes de fazer a instalação no seu ambiente, de forma a adaptá-los às suas necessidades e preferências.
• Linha 33 é muito importante dado que define a class passada ao ALARMPROGRAM referente a falta de espaço livre num dbspace. Isto deve ser ajustado ao valor da classe adicionada ao ALARMPROGRAM. Eu utilizo valores na casa dos 900 para as minhas extensões "pessoais", de forma a que não venham a sobrepor-se com classes presentes no ALARMPROGRAM, adicionadas pela IBM no futuro (não sabemos quantas poderão ser adicionadas, mas começar nos 900 dá uma margem razoável)
• Linhas 35 a 93. Aqui tentamos ler os valores configurados para os parâmetros de funcionamento acima. Estes valores são items de configuração das tarefas. Infelizmente a versão actual do OAT não permite configurá-los via interface gráfica, ou melhor, não permite criá-los. Teremos de os inserir usando SQL e depois então podemos manipulá-los via OAT. Gostaria que o processo de criação das tarefas no OAT permitisse introduzir estes parâmetros. Mas de momento (versão 2.28) isto não está disponível e portanto teremos de os inserir via SQL. Como o fazer? Estes valores são guardados na tabela ph_threshold que contém os seguintes campos:
  name: Este é o nome do parâmetro. No nosso caso, temos os seguintes: DEFAULT NUM ALARMS, DBSPACE YELLOW DEFAULT, DBSPACE RED DEFAULT e depois podemos inserir qualquer um na forma DBSPACE YELLOW dbspace_name e DBSPACE RED dbspace_name. Penso que os nomes já explicam o significado. A ideia é que se quisermos ter limites "amarelos" e "vermelhos" para dbspaces específicos temos de inserir um parâmetro com o nome DBSPACE RED/YELLOW dbspace_name na tabela ph_thresholds. Se não existir um valor específico para um determinado dbspace o procedimento irá usar o valor indicado pelo parâmetro DBSPACE RED/YELLOW DEFAULT. Se estes também não estiverem definidos, irá usar os valores definidos nas linhas 29 a 31
  task_name: O nome da tarefa na tabela ph_task. Este valor tem de se igual ao nome que dermos a esta tarefa, e esse será o que dermos na criação do agendamento para a mesma. Neste artigo usarei "IXMon Check Space". Pode usar o que desejar, desde que mantenha a coerencia
  value: O valor do limite. Este valor será usado pela tarefa. No nosso caso, os parâmetros DBSPACE RED/YELLOW * serão representados em percentagem (1-100).
  value_type: O tipo de dados do limite (STRING ou NUMERIC). No nosso caso usaremos NUMERIC. Investigando um pouco foi possível perceber que podemos usar NUMERIC(x,y) para valores fraccionados. Não testei, mas deverá funcionar, caso isso faça sentido para as suas necessidades.
  description: Uma descrição do que o limite controla. Isto será utilizado pela interface gráfice do OAT, caso posteriormente queira editar os valores pelo OAT.
  
  Para dar alguns exemplos apresento de seguida as instruções para criar os parâmetros cuja definição também existe no código (número de alarmes, limites genéricos amarelo e vermelho). Usarei os mesmo valores:
  

  INSERT INTO ph_threshold ( name, task_name, value, value_type, description)
  VALUES ( 'DEFAULT NUM ALARMS', 'IXMon Check Space', '3', 'NUMERIC', 'Numero de alarmes a enviar');
  INSERT INTO ph_threshold ( name, task_name, value, value_type, description)
  VALUES ( 'DBSPACE YELLOW DEFAULT', 'IXMon Check Space', '90', 'NUMERIC', 'Limite amarelo generico. Sera aplicado a qualquer dbspace que nao tenha um parametro especifico');
  INSERT INTO ph_threshold ( name, task_name, value, value_type, description)
  VALUES ( 'DBSPACE RED DEFAULT', 'IXMon Check Space', '95', 'NUMERIC',  'Limite vermelho generico. Sera aplicado a qualquer dbspace que nao tenha um parametro especifico');
  

  
  
  E por exemplo, se tiver um dbspace com o nome llogs_dbs, dedicato aos logical logs, que esteja practicamente cheio e que portanto não fará sentido monitorizar poderia adicionar:
  
  

  
  INSERT INTO ph_threshold ( name, task_name, value, value_type, description)
  VALUES ( 'DEFAULT YELLOW llogs_dbs', 'IXMon Check Space', '100', 'NUMERIC', 'Faz com que o llogs_dbs passe todos os teses...');
  INSERT INTO ph_threshold ( name, task_name, value, value_type, description)
  VALUES ( 'DEFAULT RED llogs_dbs', 'IXMon Check Space', '100', 'NUMERIC', 'Faz com que o llogs_dbs passe todos os teses...');
  

  
  
  
• Linha 97 cria um ciclo FOREACH. É baseado na query das linhas seguintes a qual verifica o espaço utilizado em cada dbspace do sistema.
• Linhas 98 a 111. Esta é a query referida acima. Algumas partes dela podem não ser necessárias para este efeito, mas foi retirada de outro script... Não se preocupe, deve funcionar. Dá o número de páginas e o número de páginas livres em todos os chunks do dbspace.
  Note que esta tarefa é baseada em percentagem de utilização. Poderia ser melhorada para lidar com outros tipos de parâmetros como os GB alocados, os GB livres etc. Por agora mantive-a simples.
• Linhas 114 a 153 são usadas para tentar obter limites específicos para o dbspace que está a ser processado. Se não forem encontrados na tabela ph_threshold os limites genéricos serão utilizados
• Linhas 154 a 172. Aqui calculamos a percentagem de espaço utilizado e verificamos se excede o limite amarelo ou vermelho. Se tal acontecer inicializamos a variável com a cor do alerta e a mensagem de alerta. Se estivermos abaixo do limite amarelo então deixamos a variável da cor a NULL
• Linhas 175 a 200. Se a utilização actual estiver abaixo do limite inferior (amarelo), procuramos um alerta já inserido na tabela ph_alert para este dbspace com o state igual a "NEW". Se encontrarmos alteramo-lo, mudando o estado para "ADDRESSED". Isto pode acontecer se depois de um alerta alguém apagar uma tabela por exemplo. Nesta situação não estou a chamar o ALARMPROGRAM, mas poderia fazer sentido chamá-lo com uma mensagem do tipo: "O alarme anterior para o dbspace dbspace_name foi cancelado porque estamos agora abaixo do limite definido"
• Da 204 até ao final, código que trata as situações em que excedemos um dos limites.... Assim... Primeiro pesquisamos na ph_alert para ver se temos um alarme para este dbspace no estado "NEW". Se não tivermos (223 - 239) inserimo-lo e chamamos o ALARMPROGRAM usando o procedimento referido acima. Se já tivermos um alarme verificamos se é da mesma cor. Se não for (244 - 252), fazemos um UPDATE a dois campos:
  alert_task_seq: Fazemos isto para reposicionar o contador do alarme.
  alert_color: Alteramos o código de cor do alarm (para utilização na interface do OAT). Note que nesta altura podemos ter um alarme vermelho, com um texto de mensagem referente a um amarelo. Preferi manter assim, para mostrar que houve uma alteração entre a situação original e a actual. No entanto o alarme que é enviado ao ALARMPROGRAM tem a mensagem correspondente ao alarme vermelho. Só no OAT se verá a diferença. Se o alarme tiver a mesma cor, verificamos o campo alert_task_seq e comparamo-lo com o nósso número de execução da tarefa (dado como parâmetro na chamada do procedimento) e decidimos, baseado no número de alarmes se devemos ou não chamar o ALARMPROGRAM.
  

Finalmente, como é que agendamos a tarefa? Podemos fazê-lo via interface do OAT. ou se preferir podemos inserir directamente o registo na tabela ph_task:

INSERT INTO ph_task
(
tk_id, tk_name, tk_description, tk_type, tk_dbs,
tk_execute, tk_start_time, tk_frequency,
k_monday, tk_tuesday, tk_wednesday, tk_thursday,
tk_friday, tk_saturday, tk_sunday,
tk_group, tk_enable, tk_priority
)
VALUES
(
0, 'IXMon Check Space', 'Check dbspace free space', 'TASK', 'sysadmin',
'ixmon_check_space', '00:00:00', '0 00:30:00',
't', 't', 't', 't', 't', 't', 't',
'USER','t',0
)

Atualização [ 20 Ago 2010]:

Tinha-me esquecido de um bloco condicional (IF) em volta do UPDATE que altera o estado de um alerta já existente para 'ADDRESSED' (linhas 195-200)
Como estava, o UPDATE era sempre feito mesmo quando não tinhamos encontrado um alerta. Isto não seria um erro grave, mas caso também queira chamar
o ALARMPROGRAM quando as condições do alarme são reveridas então necessitamos deste ID, ou a tarefa irá enviar alarme para cada dbspace que esteja dentro dos limites
Peço desculpa pela confusão.... Portanto adicionei o IF da linha 194 e o END IF da linha 201.




Listing 1:

DROP PROCEDURE call_alarmprogram;
CREATE PROCEDURE call_alarmprogram(
v_severity smallint,
v_class smallint,
v_class_msg varchar(255) ,
v_specific varchar(255) ,
v_see_also varchar(255)
)


--   severity: Category of event
--   class-id: Class identifier
--   class-msg: string containing text of message
--   specific-msg: string containing specific information
--   see-also: path to a see-also file

DEFINE v_command CHAR(2000);
DEFINE v_alarmprogram VARCHAR(255);

--SET DEBUG FILE TO '/tmp/call_alarmprogram.dbg' WITH APPEND;
--TRACE ON;

SELECT
cf_effective
INTO
v_alarmprogram
FROM
sysmaster:sysconfig
WHERE
cf_name = "ALARMPROGRAM";

LET    v_command = TRIM(v_alarmprogram) || " " || v_severity || " " || v_class || " '" || v_class_msg || "' '" || NVL(v_specific,v_class_msg) || "' '" || NVL(v_see_also,' ') || "'";
SYSTEM v_command;
END PROCEDURE;

Listing 2:

 1 DROP FUNCTION ixmon_check_space;
 2 CREATE FUNCTION "informix".ixmon_check_space(task_id INTEGER, v_id INTEGER) RETURNING INTEGER
 3
 4 DEFINE v_default_num_alarms, v_num_alarms SMALLINT;
 5 DEFINE v_default_yellow_threshold, v_default_red_threshold SMALLINT;
 6 DEFINE v_generic_yellow_threshold, v_generic_red_threshold SMALLINT;
 7 DEFINE v_dbs_yellow_threshold, v_dbs_red_threshold SMALLINT;
 8 DEFINE v_name LIKE ph_threshold.name;
 9 DEFINE v_dbsnum INTEGER;
10 DEFINE v_dbs_name CHAR(128);
11 DEFINE v_pagesize, v_is_blobspace, v_is_sbspace, v_is_temp SMALLINT;
12 DEFINE v_size, v_free BIGINT;
13 DEFINE v_used DECIMAL(4,2);
14 DEFINE v_alert_id LIKE ph_alert.id;
15 DEFINE v_alert_task_seq LIKE ph_alert.alert_task_seq;
16 DEFINE v_alert_color,v_current_alert_color CHAR(6);
17 DEFINE v_message VARCHAR(254,0);
18
19 DEFINE v_severity, v_class SMALLINT;
20 ---------------------------------------------------------------------------
21 -- Uncomment to activate debug
22 ---------------------------------------------------------------------------
23 --SET DEBUG FILE TO '/tmp/ixmon_check_space.dbg' WITH APPEND;
24 --TRACE ON;
25
26 ---------------------------------------------------------------------------
27 -- Default values if nothing is configured in ph_threshold table
28 ---------------------------------------------------------------------------
29 LET v_default_yellow_threshold=90;
30 LET v_default_red_threshold=95;
31 LET v_default_num_alarms=3;
32
33 LET v_class = 908;
34
35 ---------------------------------------------------------------------------
36 -- Get the number of times to call the alarm...
37 ---------------------------------------------------------------------------
38
39 LET v_num_alarms=NULL;
40
41 SELECT
42  value
43 INTO
44  v_num_alarms
45 FROM
46  ph_threshold
47 WHERE
48  task_name = 'IXMon Check Space' AND
49  name = 'DEFAULT NUM ALARMS';
50
51 IF v_num_alarms IS NULL
52 THEN
53  LET v_num_alarms=v_default_num_alarms;
54 END IF;
55
56 ---------------------------------------------------------------------------
57 -- Get the defaults configured in the ph_threshold table
58 ---------------------------------------------------------------------------
59 LET v_generic_yellow_threshold=NULL;
60 LET v_generic_red_threshold=NULL;
61
62 SELECT
63  value
64 INTO
65  v_generic_yellow_threshold
66 FROM
67  ph_threshold
68 WHERE
69  task_name = 'IXMon Check Space' AND
70  name = 'DBSPACE YELLOW DEFAULT';
71
72 IF v_generic_yellow_threshold IS NULL
73 THEN
74  LET v_generic_yellow_threshold=v_default_yellow_threshold;
75 END IF;
76
77
78
79 SELECT
80  value
81 INTO
82  v_generic_red_threshold
83 FROM
84  ph_threshold
85 WHERE
86  task_name = 'IXMon Check Space' AND
87  name = 'DBSPACE RED DEFAULT';
88
89 IF v_generic_red_threshold IS NULL
90 THEN
91  LET v_generic_red_threshold=v_default_red_threshold;
92 END IF;
93
94 ---------------------------------------------------------------------------
95 -- Foreach dbspace....
96 ---------------------------------------------------------------------------
97 FOREACH
98  SELECT
99   d.dbsnum, d.name, d.pagesize, d.is_blobspace, d.is_sbspace, d.is_temp,
100   SUM(c.chksize), SUM(c.nfree)
101  INTO
102   v_dbsnum, v_dbs_name, v_pagesize, v_is_blobspace, v_is_sbspace, v_is_temp,
103   v_size, v_free
104  FROM
105   sysmaster:sysdbspaces d, sysmaster:syschunks c
106  WHERE
107   d.dbsnum = c.dbsnum
108  
109  
110  GROUP BY 1, 2, 3, 4, 5, 6
111  ORDER BY 1
112 
113
114  ---------------------------------------------------------------------------
115  -- Get specific dbspace red threshold if available....
116  ---------------------------------------------------------------------------
117  LET v_name = 'DBSPACE RED ' || TRIM(v_dbs_name);
118
119  SELECT
120   value
121  INTO
122   v_dbs_red_threshold
123  FROM
124   ph_threshold
125  WHERE
126   task_name = 'IXMon Check Space' AND
127   name = v_name;
128
129  IF v_dbs_red_threshold IS NULL
130  THEN
131   LET v_dbs_red_threshold = v_generic_red_threshold;
132  END IF;
133
134  ---------------------------------------------------------------------------
135  -- Get specific dbspace yellow threshold if available....
136  ---------------------------------------------------------------------------
137  LET v_name = 'DBSPACE YELLOW ' || TRIM(v_dbs_name);
138
139  SELECT
140   value
141  INTO
142   v_dbs_yellow_threshold
143  FROM
144   ph_threshold
145  WHERE
146   task_name = 'IXMon Check Space' AND
147   name = v_name;
148
149  IF v_dbs_yellow_threshold IS NULL
150  THEN
151   LET v_dbs_yellow_threshold = v_generic_yellow_threshold;
152  END IF;
153
154  ---------------------------------------------------------------------------
155  -- Calculate used percentage and act accordingly...
156  ---------------------------------------------------------------------------
157  LET v_used = ROUND( ((v_size - v_free) / v_size)  * 100,2);
158  IF v_used > v_dbs_red_threshold
159  THEN
160   LET v_alert_color = 'RED';
161   LET v_message ='DBSPACE ' || TRIM(v_dbs_name) || ' exceed the RED threshold (' ||v_dbs_red_threshold||'). Currently using ' || v_used ;
162   LET v_severity = 4;
163  ELSE
164   IF v_used > v_dbs_yellow_threshold
165   THEN
166    LET v_alert_color = 'YELLOW';
167    LET v_message ='DBSPACE ' || TRIM(v_dbs_name) || ' exceed the YELLOW threshold (' ||v_dbs_yellow_threshold||'). Currently using ' || v_used ;
168    LET v_severity = 3;
169   ELSE
170    LET v_alert_color = NULL;
171   END IF
172  END IF
173
174
175  IF v_alert_color IS NULL
176  THEN
177   ---------------------------------------------------------------------------
178   -- The used space is lower than any of the thresholds...
179   -- check to see if there is an already inserted alarm
180   -- If so... clear it...
181   ---------------------------------------------------------------------------
182   LET v_alert_id = NULL;
183
184   SELECT
185    p.id, p.alert_task_seq, p.alert_color
186   INTO
187    v_alert_id, v_alert_task_seq, v_current_alert_color
188   FROM
189    ph_alert p
190   WHERE
191    p.alert_task_id = task_id
192    AND p.alert_object_name = v_dbs_name
193    AND p.alert_state = "NEW";
194   IF v_alert_id IS NOT NULL
195    UPDATE
196     ph_alert
197    SET
198     alert_state = 'ADDRESSED'
199    WHERE
200     ph_alert.id = v_alert_id;
201   END IF;
202  ELSE
203  
204   ---------------------------------------------------------------------------
205   -- The used space is bigger than one of the thresholds...
206   -- Check to see if we already have an alert in the ph_alert table in the
207   -- state NEW ...
208   ---------------------------------------------------------------------------
209
210   LET v_alert_id = NULL;
211
212   SELECT
213    p.id, p.alert_task_seq, p.alert_color
214   INTO
215    v_alert_id, v_alert_task_seq, v_current_alert_color
216   FROM
217    ph_alert p
218   WHERE
219    p.alert_task_id = task_id
220    AND p.alert_object_name = v_dbs_name
221    AND p.alert_state = "NEW";
222
223   IF v_alert_id IS NULL
224   THEN
225    ---------------------------------------------------------------------------
226    -- There is no alarm... or the alarm changed from NEW
227    ---------------------------------------------------------------------------
228   
229    INSERT INTO
230     ph_alert (id, alert_task_id, alert_task_seq, alert_type, alert_color, alert_time,
231     alert_state, alert_state_changed, alert_object_type, alert_object_name, alert_message,
232     alert_action_dbs)
233    VALUES(
234     0, task_id, v_id, 'WARNING', v_alert_color, CURRENT YEAR TO SECOND,
235     'NEW', CURRENT YEAR TO SECOND,'DBSPACE', v_dbs_name, v_message, 'sysadmin');
236 
237    EXECUTE PROCEDURE call_alarmprogram(v_severity, v_class, 'DBSPACE used space too high',v_message,NULL);
238
239   ELSE
240    ---------------------------------------------------------------------------
241    -- There is an alarm...
242    -- Need to check if it's still the same color...
243    ---------------------------------------------------------------------------
244    IF v_current_alert_color != v_alert_color
245    THEN
246     ---------------------------------------------------------------------------
247     -- Change the color... And reset the seq to reactivate the couter...
248     ---------------------------------------------------------------------------
249     UPDATE ph_alert
250     SET (alert_task_seq, alert_color) = (v_id,v_alert_color)
251     WHERE ph_alert.id = v_alert_id;
252     EXECUTE PROCEDURE call_alarmprogram(v_severity, v_class, 'DBSPACE used space too high',v_message,NULL);
253    ELSE
254     IF (v_id < v_alert_task_seq + v_num_alarms) OR v_num_alarms = 0 
255     THEN
256      EXECUTE PROCEDURE call_alarmprogram(v_severity, v_class, 'DBSPACE used space too high',v_message,NULL);
257     END IF;
258    END IF;
259   END IF;
260  END IF;
261 END FOREACH
262 
263 END FUNCTION;

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


English version:

Some time ago, during a customer engagement, I felt the need to be able to show them if there were lock waiting sessions in their most busy system. Of course any old time Informix DBA will tell that onstat -k/K is able to provide this. But in their environment they needed this to be available to a broader audience than just the DBA team (who are the ones with database server command line access). So we decided to create a simple PHP script with Informix connection that showed it in a web page available in their Intranet. They're currently moving into using Open Admin Tool (OAT) and I though it would be nice to move that into OAT. Note that OAT already includes some reports that provide similar (although with less detail) information (session waiting report).
So I thought it would be nice to do it properly and create a plug-in. I searched around, specifically in OAT's home ( http://www.openadmintool.org ) and found a link to an article about creating plugins in OAT: http://www.ibm.com/developerworks/db2/library/techarticle/dm-0808vonbargen/
The author of this article is Erika Von Bargen, an IBM colleague, which is very active in the OAT specific IIUG mailing list. People who went to this year's IIUG conference possibly also know her since she was there presenting sessions about OAT.
Now... To tell you the complete truth, sometimes I'm very lazy (aren't we all at times?) when it comes to properly read documentation. So I just jumped into a terminal and started looking at an example plug-in provided with OAT. In a few minutes I had changed the query and I was seeing the information we were used to see in the customized web page. Obviously every message and column header was missing, the menus were wrong etc. But It was enough to become enthusiastic about this subject. I posted a few messages in OAT's mailing list, and had a quick feedback from Erika, which was a great help.
After the initial startup I decided to do it properly, and I read the article above, and it's a nice, clear and concise article. It's perfect to get you started.

So, after the initial "code, test, fix error, test....", instead of the "read, plan, code, test, fix..." I was ready to do it properly and I took some time at home to play with this. And I kept adding some features, some usability details and finally got to a point where I think I have a working plug-in. It has four options:

1. List all the instance locks
   This shows information similar to onstat -K, but most of the information is immediately readable (meaning you don't have to query sysmaster to get the table names, and you don't have to run onstat -u | grep .... to get the session number.
2. List locks with waiters
   This shows information on every lock that has a lock list. The information includes:
   - The owner username, session number, process id and client machine
   - The waiter username, session number, process id and client machine
   - The table/index in question, the time the lock was established and how long the wait is waiting
   
3. List locks per table
   This shows information about locking for every active table in your system. The information includes the number of currently held locks, the number of lock requests made on the table, the number of lock waits, the number of deadlocks and the number of lock timeouts
   
4. List locks per session
   This shows the number of currently held locks, the number of lock requests made by the session, the number of lock waits, the number of deadlocks and the number of lock timeouts

One of the great things about OAT is how easy we can localize our plug-ins. In this case, due to my linguistic limitations, I've only included the standard English messages and naturally the Portuguese ones. I'd be glad to add more, if people who can write in other languages (already used by OAT) could send me the translated messages. The number of words/phrases to translate is really short and to be honest I'm tempted to give some online translation a try... But I would prefer some user contributions, in case you find the plug-in useful....
Also, I'd love to receive feedback about bugs or improvements. I have a few ones on my mind, but it's always better to listen to others...

So, where is it? I've just upload it to IIUG software repository. It's the first time I do it, so I'm not sure how long will it take to become available
[UPDATE 31 Aug 2010]: It's already available on the IIUG repository .

If you want to check the aspect of it, before giving it a try, please see below some snapshots.

How stable is it? It wasn't tested on big systems. But all it does is query the sysmaster. So, the worst thing that could happen would be giving you some wrong information. It should not do any harm to your system. In any case treat this as a beta release for now. One thing that can happen is that the pages show all the information fetched by the queries. In large systems, with thousands of locks, sessions, or tables, this can translate into very big HTML pages... Be aware of this.
To the best of my knowledge the queries return proper results. The locks with waiters page is based on a query being used for a fairly long time. The other queries were created and tested in a very controlled environment, so admittedly it's possible that they don't cover some situations.

Every feedback is welcome. Although OAT already includes some functionality in this area, I think this will give you a more direct and condensed tool to monitor your database locking activity. As such I believe the plug-in can be useful and it certainly can be improved.


Versão portuguesa:


Há algum tempo atrás, durante um trabalho num cliente, senti a necessidade de lhes mostrar se tinham sessões à espera de locks no sistema mais utilizado. Claro que qualquer DBA Informix com alguma experiência dirá que o onstat -k/K é capaz de responder a esta necessidade. Mas no caso que refiro, era necessário que esta informação estivesse disponível para uma audiência mais alargada que apenas a equipa de DBAs (os únicos com acesso à linha de comando no servidor de base de dados).
Por isso, decidimos criar um script PHP, simples, com conexão ao Informix, que mostrasse a informação numa página Web disponível na Intranet da empresa. Actualmente estão a começar a usar o Open Admin Tool (OAT) e pareceu-me adequado colocar esta funcionalidade dentro da mesma ferramenta. Note-se que o OAT já fornece informaçao semelhante (embora com menos detalhe) no relatório de sessões em espera.
Assim pensei que seria bom fazer isto como deve ser e criar um plug-in. Procurei informação, especificamente no website do OAT ( http://www.openadmintool.org ) e encontrei uma ligação a um artigo sobre criação de plug-ins para o OAT: http://www.ibm.com/developerworks/db2/library/techarticle/dm-0808vonbargen/

A autora deste artigo é a Erika Von Bargen, uma colega da IBM, bastante activa na mailing list do OAT do IIUG. Quem teve oportunidade de estar na conferência do IIUG este ano também teve oportunidade de assistir a sessões apresentadas por ela, precisamente relacionadas com o OAT
Bom... Para ser franco, ocasionalmente sou bastante preguiçoso (não seremos todos de vez em quando?) quando toca a ler documentação. Por isso, abri uma sessão e comecei a estudar um exemplo de plug-in fornecido com o OAT. Em apenas alguns minutos, tinha mudado a query que lhe serve de base e estava a ver a informação a que estávamos habituados na página personalizada. Naturalmente, todas as mensagens e cabeçalhos de tabelas estavam errados ou em falta, os menus estavam errados etc. Mas foi o suficiente para me tornar um entusiasta do assunto. Coloquei algumas mensagens na mailing list do OAT e obtive respostas rápidas da Erika que foram uma grande ajuda.
Após o arranque inicial, decidi que devia fazer as coisas devidamente, e li o artigo mencionado acima, que é bom, claro e conciso. Ideal para quem quer começar com a tarefa de criar um plug-in.

Assim, após a abordagem inicial de "codificar, testar, corrigir erros, testar....", passei para a de "ler, planear, codificar, testar, corrigir....". Estava preparado para fazer isto como deve ser e disponibilizei algum tempo em casa para "brincar" com isto. E fui adicionando funcionalidades, detalhes para melhorar a usabilidade, e finalmente cheguei a um ponto onde julgo ter um plug-in que funciona.
Tem quatro opções:

1. Listar os bloqueios na instância
   Isto mostra informação semelhante ao onstat -K, mas a maioria da informação é de leitura imediata (ou seja, não é necessário pesquisar na sysmaster para obter os nomes das tabelas, e não temos de correr um onstat -u | grep ... para obter o número da sessão
2. Listar os bloqueios com fila de espera
   Isto mostra informação de cada bloqueio que tenha uma lista de espera. Esta informação incluí:
   - O dono do bloqueio, incluindo nome de utilizador, número de sessão, número de processo e a máquina cliente
   - Quem está à espera, incluíndo o nome de utilizador, número de sessão, número de processo e a máquina cliente
   - A tabela/indíce que tem o bloqueio, o instante em que o bloqueio foi estabelecido e há quanto tempo existe a espera
3. Listar os bloqueios por tabela
   Isto mostra informação sobre os bloqueios para todas as tabelas activas do seu sistema.
   A informação incluí o número de bloqueios activos no momento, o número de pedidos de bloqueios feitos sobre a tabela, o número de esperas por bloqueios sobre a tabela, o número de deadlocks que envolveram a tabela, e o número de vezes que os tempos de espera por bloqueios expiraram
4. Listar os bloqueios por sessão
   Isto mostra o número de bloqueios que cada sessão mantém activos, o número de pedidos de bloqueio feitos pelas sessões, o número de esperas por bloqueios, o número de deadlocks da sessão, e o número de tempos de espera por bloqueios expirados
   
   

Uma das coisas boas do OAT é a facilidade com que se pode localizar ou traduzir os nossos plug-ins. Devido às minhas limitações linguísticas, neste caso, o plug-in só incluí as mensagens em Ingês (standard) e naturalmente em Português. Gostaria de adicionar mais, caso quem escreva noutras línguas (das já usadas pelo OAT) me queira enviar as mensagens traduzidas. O número de palavras/frases a traduzir é realmente pequeno, e para ser honesto sinto-me tentado a experimentar os tradutores automáticos online. Mas seria preferível se alguém contribuísse caso considere o plug-in útil.

Adicionalmente, terei todo o gosto em receber comentários sobre bugs ou melhorias. Tenho algumas em mente, mas é sempre melhor escutar opiniões de outros...

Então, onde está o plug-in? Acabei de fazer o envio para o repositório de software do IIUG. É a primeira vez que o faço, e sinceramente não sei quanto tempo levará a ficar disponível.
[ACTUALIZAÇÂO 31 Aug 2010]: Já está disponível no repositório de software do IIUG.

Se desejar ver o aspecto do plug-in, antes de o testar, por favor veja as imagens abaixo.

Quão estável é o plug-in? Não foi testado em sistemas grandes. Mas tudo o que faz é pesquisar a sysmaster. Por isso, além de alguma possível informação errada não deverá causar qualquer problema nos seus sistemas. Em todo o caso trate isto como uma release beta por enquanto. Algo que pode acontecer é que as páginas mostram toda a informação obtida nas queries. Em sistemas grandes, com milhares de bloqueios, sessões ou tabelas, isto pode traduzir-se em páginas HTML muito grandes.... Tenha algum cuidado com isso.
Tanto quanto me apercebi, as pesquisas retornam resultados correctos. A lista de bloqueios com lista de espera baseia-se numa query que utilizo há bastante tempo. As outras pesquisas foram criadas e testadas num ambiente muito controlado, logo é possível que possam não prever algumas situações.

Todo o feedback será muito bem vindo. Apesar de o OAT já incluir alguma funcionalidade nesta área, julgo que este plug-in será uma ferramenta mais directa e condensada para monitorizar toda a actividade relacionada com bloqueios nas suas instâncias Informix. Como tal, acredito que o plug-in possa ser útil e certamente poderá ser melhorado.


Snapshots/Écrans:

















Lock List
Lista de bloqueios


















Lock waiters
Lista de bloqueios com fila de espera

















Locks per table
Bloqueios por tabela























Locks per session
Bloqueios por sessão

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


English Version:

Andrew Ford already announced this in his blog, so for the English version I'll just recommend that you check his article. Basically there will be a very important Chat with the labs session on August 26. For all the customers still in version 9.40 and v10, this may really make a difference.

Portuguese Version:

No dia 26 de Agosto decorrerá mais uma sessão "Chat with the labs" sobre o tema "opções de suporte após o fim de serviço e melhores prácticas para upgrades ou actualizações".
A IBM disponibiliza várias opções de suporte para clientes cujos productos tenham atingido o fim de serviço, e esse será o tema principal desta sessão.
O tema será mais relevante para clientes que estejam ainda a correr as versões 7.31 (sem suporte normal desde Setembro de 2008), a 9.40 (sem suporte normal desde Abril de 2008) e a 10 que deixará de ter suporte normal no próximo dia 30 de Setembro.
Na sessão serão também abordadas as melhores estratégias e prácticas para migrações da versão 10 para a 11.50.

Para assistir à sessão deverá registar-se em:

https://events.webdialogs.com/register.php?id=d6def198fd&l=en-US

Os slides deverão estar disponíveis antes da conferência em:

http://www.ibm.com/informix/labchats

Caso não lhe seja possível assistir em directo poderá obter os slides e mais tarde som. Caso o tema seja útil, e em caso de dúvida não deixe de contactar o seu representante IBM.

This article will be written in English and Portuguese.
Este artigo será escrito em Inglês e Português.

English version:

A few articles ago I tried to lecture on how to do a good troubleshooting. And I wrote that it all starts with an error or a bad behavior. When we have an error we should start from there. If we don't have it, it's harder.... But what about the situations when we have an error that says:

"No error message available"

Not good... I faced a situation on a customer where this happened. It's a Web application written in ASP using the windows driver (OleDB) and running on IIS. After an engine restart they started having an error that says:

No error message available, result code: E_UNEXPECTED(0x8000FFFF)
ErrorCode -2147418113

So, we had an error, but it wasn't really helpful. It wasn't too hard to find out what happened, since this particular engine has some variables to avoid problems with code set conversions and it was started without those variables in the environment. But It would have been quicker to understand if we had a proper error code. So, after solving the main issue, I dig in to the subject and found a very interesting APAR:

IC64220: THREADED OLEDB DOES NOT RETURN THE CORRECT ERROR MESSAGE

Basically, the driver was doing a bad use of the MS API to expose errors and in some situations the error structures were not properly initialized. This caused the "No error message available" information.
The fix is in CSDK 3.50.xC5 and if nothing else, this would be a good reason to upgrade.
It was not the first time I had "weird errors" in Windows environment, and in fact there were other similar bugs reported. So I leave here the suggestion to upgrade. Obviously, like with any other upgrade, test, test, test....

Portuguese version:

Há alguns artigos atrás eu dei um "sermão" sobre como fazer um bom despiste de problemas. E escrevi que tudo deve começar com um erro ou com um mau comportamento. Quando temos um erro devemos começar por aí. Se não tivermos é mais dificíl.... Mas e se tivermos um erro que diz:

"No error message available"

Nada bom... Encontrei uma situação num cliente onde isto apareceu. É uma aplicação Web escrita em ASP utilizando os drivers Windows (OleDB) a correr em IIS. Após uma paragem de um motor, começaram a ter o seguinte erro:

No error message available, result code: E_UNEXPECTED(0x8000FFFF)
ErrorCode -2147418113

Portanto, tinhamos um erro, mas não era grande ajuda. Não foi muito difícil descobrir o que se tinha passado, dado que este motor em particular tem algumas variáveis posicionadas para evitar problemas na conversão de caracteres entre diferentes mapas ou codesets, e estas variáveis não estavam posicionadas quando se arrancou com o motor. Mas teria sido mais rápido de entender se tivéssemos tido um código e mensagem de erro válidos. Assim, após resolver o problema principal, investiguei um pouco mais e encontrei o seguinte APAR:


IC64220: THREADED OLEDB DOES NOT RETURN THE CORRECT ERROR MESSAGE

Basicamente, o driver estava a fazer uma utilização errada da API da MS para expor erros, e em determinadas situações as estruturas de erro não eram devidamente inicializadas. Isto causava a mensagem "No error message available"

A correcção está no CSDK 3.50.xC5, e mesmo só por isto já seria uma boa razão para fazer a actualização.
Não foi a primeira vez que me deparei com erros "estranhos" no ambiente Windows, e na verdade havia outros bugs semelhantes reportados. Assim, deixo a sugestão para se fazer a actualização. Claro que em qualquer situação de actulização de versões, a ordem é testar, testar, testar....

This article will be in English and Portuguese.
Este artigo será em Inglês e Português

English version:

After the announcements in May, new changes were made to Informix packaging. Basically the free versions for Windows and Mac OSX (Ultimate-C) were withdrawn. To replace them the Innovator-C version (also free, but with lower usage limits) will be available for all platforms (including the Windows and Mac OSX).

Also a new edition will be available, called Choice Edition, just for Windows and Mac OSX. This one will have license costs, but is cheaper than Growth Edition. The limits are higher than Innovator-C and lower than Growth Edition.

I believe these changes have created some confusion, but there are some important points to note:

1. Clients will still be able to use a version without license costs for all platforms supported by Informix (Innovator-C). The usage limitations are fairly acceptable for a lot of usages
2. Windows and Mac OSX are target platforms with a more aggressive price, considering Choice Edition (again, with fairly respectable functionality and usage limits)
3. Existing customers are not necessarily affected by the new editions. They already payed for the licenses, and are (probably) paying maintenance/support. Obviously they can consider the new editions for new deployments
4. Existing Enterprise Edition customers get more value, because Ultimate Edition includes more features than the Enterprise

The last changes were announced a few days ago and are explained in IIUG website, more specifically here:
http://www.iiug.org/news/announcements/new_prices.php

I delayed the publishing of this article because I was expecting the website comparing the different versions to be updated:

http://www.ibm.com/developerworks/data/library/techarticle/dm-0801doe/

This is the best, and the official place to check each version available functionality.

Other links:

• Article from Andrew Ford about the same topic. It includes links some detailed analysis about each version limitations:
  http://www.informix-dba.com/2010/07/new-phone-bookss-here-informix.html
  

Versão Portuguesa:

Depois dos anúncios em Maio, novas alterações foram feitas nas versões de Informix disponíveis. Basicamente as versões grátis para Windows e Mac OSX (Ultimate-C) foram descontinuadas. Para as substituir a versão Innovator-C (igualmente grátis, mas com limites de utilização mais baixos) estará disponível para todas as plataformas (incluindo Windows e Mac OSX)

Uma nova versão estará disponível, designada por Choice Edition, apenas para Windows e Mac OSX. Esta versão terá custos de licenciamento, mas será mais barata que a Growth Edition. Os limites situam-se entre a Innovator-C e a Growth Edition.

Acredito que estas alterações provoquem alguma confusão, mas há que salientar alguns pontos:

1. Os clientes poderão utilizar uma versão sem custos em todas as plataformas suportadas pelo Informix (Innovator-C). As funcionalidades incluídas e os limites impostos não deverão ser obstáculo a um leque grande de ambientes.
2. Windows e Mac OSX são plataformas alvo, com preços mais agressivos, considerando a versão Choice (também com funcionalidades e limites de utilização bastante respeitáveis.
3. Os clientes existentes não são necessariamente afectados pelas novas versões. Na realidade o custo das licenças já foi pago, e o que estarão (provavelmente) a pagar são os custos de manutenção/suporte. Naturalmente poderão considerar as novas versões para novos projectos.
4. Clientes actuais da Enterprise Edition obtém mais valor, porque a versão Ultimate incluí mais funcionalidade que a Enterprise

As últimas alterações foram anunciadas alguns dias atrás e estão explicadas no website do IIUG, mais especificamente aqui:

http://www.iiug.org/news/announcements/new_prices.php

Atrasei um pouco a publicação deste artigo porque estava à espera que o website que tem a comparação entre as versões fosse actualizado:

http://www.ibm.com/developerworks/data/library/techarticle/dm-0801doe/

Este é o melhor sitio (e o oficial) para verificar as funcionalidades e limites de cada versão.

Outros links:

• Artigo do Andrew Ford (Inglês) sobre o mesmo tema. Tem links para análises detalhadas das limitações das várias versões:
  http://www.informix-dba.com/2010/07/new-phone-bookss-here-informix.html