Monday, August 30, 2010

Briug / Briug :)

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.

Friday, August 27, 2010

Out of support? Not yet! / Fora de suporte? Ainda não

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)

Tuesday, August 24, 2010

New IBM Redbook / Novo Redbook IBM

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.

Saturday, August 14, 2010

OAT: monitor dbspace usage / Monitorização de ocupação de dbspaces

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;