Introdução ao Oracle Cluster Health Advisor

Por Rogerio Eguchi
Publicado em Abril 2018

Revisado por Victor Ambrsut



Esse artigo trará ao leitor conhecimento sobre o Oracle Cluster Health Advisor (CHA), ferramenta que compõe o Oracle 12c

Autonomous Health Framework, e está disponível a partir da versão 12.2 nas instalações de Oracle GridInfrastructure para Oracle RAC.

A missão do CHA é ser um componente consultivo, ou seja, entregar ao DBA diagnóstico e correção de problemas para o Cluster e Bancos RAC.

O CHA é um processo daemon instalado por padrão em cada nó do cluster. Veja:

O resultado das análises, assim como as informações de diagnóstico, o plano de ação de correção e métricas de evidência são armazenados no Grid Infrastructure Management Repository (GIMR). O CHA também envia mensagens de aviso para o Enterprise Manager Cloud Control utilizando o protocolo de notificação de eventos do Oracle Clusterware.



Arquitetura do Oracle Cluster Health Advisor

O CHA é executado, em cada um dos nodes, como um recurso de alta disponibilidade do cluster. Cada daemon (ochad) monitora o sistema operacional e, opcionalmente a instance de banco de dados Oracle RAC.



Monitorando o Oracle RAC com o Cluster Health Advisor

O CHA não necessita de configurações adicionais.

Quando ele detecta uma instance de banco Oracle Real Application Clusters ou Oracle RAC One Node, de forma autônoma inicia-se a monitoração do cluster.

Utilize-se da ferramenta CHCTL para interagir com o CHA, utilizando usuário de instalação do Grid Infrastructure.

As opções de sintaxe são:

chactl monitor cluster [-model <model_name> [-force]]

chactl monitor database -db <db_unique_name>

                        [-model <model_name> [-force]]

chactl unmonitor database -db <db_unique_name>

chactl status [cluster|database [-db <db_unique_name>]] [-verbose]

chactl config [cluster|database -db <dbname>]

chactl calibrate {cluster|database -db <db_unique_name>}

                 -model <model_name> [-force]

                 [-timeranges 'start=<time_stamp>,end=<time_stamp>,...']

                 [-kpiset 'name=<kpi_name> min=<val> max=<val>,...' ]

    WHERE:

        -interval <val> : interval is in hrs

        -timeranges 'start=<time_stamp>,end=<time_stamp>,...' :

             Timestamp must be in format 'YYYY-MM-DD HH24:MI:SS'

    KPI for db:

        CPUPERCENT - CPU utilization - Percent

        IOREAD - Disk read - Mbyte/sec

        DBTIMEPERCALL - Database time per user call - usec/call

        IOWRITE - Disk write - Mbyte/sec

        IOTHROUGHPUT - Disk throughput - IO/sec

    KPI for cluster:

        CPUPERCENT - CPU utilization - Percent

        IOREAD - Disk read - Mbyte/sec

        IOWRITE - Disk write - Mbyte/sec

        IOTHROUGHPUT - Disk throughput - IO/sec

chactl query diagnosis [-cluster|-db <db_uniq_name>]

                       [-start <time> -end <time>]

                       [-htmlfile <file_name>]

chactl query model [-name <model_name> [-verbose]]

chactl query repository

chactl query calibration {-cluster|-db <db_uniq_name>}

        [-timeranges 'start=<time_stamp>,end=<time_stamp>,...']

        [-kpiset 'name=<kpi_name> min=<val> max=<val>,...' ]

        [-interval <val>]

    WHERE:

        -interval <val> : interval is in hrs

        -timeranges 'start=<time_stamp>,end=<time_stamp>,...' :

             Timestamp must be in format 'YYYY-MM-DD HH24:MI:SS'

    KPI for db:

        CPUPERCENT - CPU utilization - Percent

        IOREAD - Disk read - Mbyte/sec

        DBTIMEPERCALL - Database time per user call - usec/call

        IOWRITE - Disk write - Mbyte/sec

        IOTHROUGHPUT - Disk throughput - IO/sec

    KPI for cluster:

        CPUPERCENT - CPU utilization - Percent

        IOREAD - Disk read - Mbyte/sec

        IOWRITE - Disk write - Mbyte/sec

        IOTHROUGHPUT - Disk throughput - IO/sec

chactl remove model -name <model_name>

chactl rename model -from <model_name> -to <model_name>

chactl import model -name <model_name> -file <model_file> [-force]

chactl export model -name <model_name> -file <output_file>

chactl set maxretention -time <retention_time>

chactl resize repository -entities <total # of hosts and database instances> [-force | -eval]

  

Veja que, conforme falado anteriormente, a monitoração da base é opcional e está desativada:


Para a ativar a monitoração da base, execute o comando: chactl monitor database –db db_unique_name

Exemplo:

Para parar a monitoração da base, execute o comando: chactl nomonitor database –db db_unique_name




Análise de diagnóstico através do Oracle Cluster Health Advisor

O CHA abre e encerra problemas de forma autônoma, armazenando o histórico no Grid Infrastructure Management Repository (GIMR).

Para consultar os dados de diagnóstico, execute o comando: chactl query diagnosis -db db_unique_name -start time -end time

Exemplo:

Dica: Utilize a opção -htmlfile file_name, para gerar o resultado em formato HTML.

Utilizando a ferramenta SwingBench (http://dominicgiles.com/swingbench.html) e gerando carga sob o ambiente pode-se observar as descobertas do CHA para esse cenário:




Calibrando o Oracle Cluster Health Advisor

É possível “calibrar” a ferramenta para que ela entenda melhor a carga do seu ambiente.

Recomenda-se um mínimo de 6 horas de dados disponíveis e que ambos, cluster e banco, sejam calibrados no mesmo período.

Utilize o comando chactl query calibration para verificar se existem dados disponíveis para execução do calibrate. O output será algo como:

[grid@raclab1 ~]$ chactl query calibration -db cdbrac

Database name : cdbrac

Start time : 2017-10-23 14:46:05

End time : 2017-10-23 15:41:50

Total Samples : 1337

Percentage of filtered data : 100%


1) Disk read (ASM) (Mbyte/sec)

MEAN      MEDIAN    STDDEV    MIN       MAX
0.03      0.00      0.09      0.00      1.66

<25       <50       <75       <100      >=100
100.00%   0.00%     0.00%     0.00%     0.00%


2) Disk write (ASM) (Mbyte/sec)

MEAN      MEDIAN    STDDEV    MIN       MAX
0.02      0.00      0.16      0.00      4.77

<50       <100      <150      <200      >=200
100.00%   0.00%     0.00%     0.00%     0.00%


3) Disk throughput (ASM) (IO/sec)

MEAN      MEDIAN    STDDEV    MIN       MAX
0.82      0.00      10.56     0.00      200.00

<5000     <10000    <15000    <20000    >=20000
100.00%   0.00%     0.00%     0.00%     0.00%


4) CPU utilization (total) (%)

MEAN      MEDIAN    STDDEV    MIN       MAX
10.20     7.90      9.83      2.20      92.60

<20       <40       <60       <80       >=80
94.99%    2.84%     1.12%     0.07%     0.97%


5) Database time (per user call) (usec/call)

MEAN      MEDIAN    STDDEV    MIN       MAX
1674.03   0.00      4695.77   0.00      79561.00

<10000000  <20000000  <30000000  <40000000  <50000000  <60000000  <70000000  >=70000000
100.00%    0.00%       0.00%     0.00%      0.00%      0.00%      0.00%      0.00%


Database name : cdbrac

Start time : 2017-10-23 15:41:50

End time : 2017-10-23 17:38:35

Total Samples : 2690

Percentage of filtered data : 100%


1) Disk read (ASM) (Mbyte/sec)

MEAN      MEDIAN    STDDEV    MIN       MAX
68.30     0.00      116.13    0.00      320.63

<25       <50       <75       <100      >=100
82.57%    0.15%     0.00%     0.19%     1.71%


2) Disk write (ASM) (Mbyte/sec)

MEAN      MEDIAN    STDDEV    MIN       MAX
4.63      0.00      9.08      0.00      52.48

<50       <100      <150      <200      >=200
99.96%    0.04%     0.00%     0.00%     0.00%


3) Disk throughput (ASM) (IO/sec)

MEAN      MEDIAN    STDDEV    MIN       MAX
625.55    0.00      1348.09   0.00      3569.46

<5000     <10000    <15000    <20000    >=20000
100.00%   0.00%     0.00%     0.00%     0.00%


4) CPU utilization (total) (%)

MEAN      MEDIAN    STDDEV    MIN       MAX
17.87     8.90      18.15     2.20      100.00

<20       <40       <60       <80       >=80
73.56%    5.19%     19.28%    0.78%     0.78%


5) Database time (per user call) (usec/call)

MEAN      MEDIAN    STDDEV    MIN       MAX
11648.95  429.00    143472.93  0.00      5532863.00

<10000000  <20000000  <30000000  <40000000  <50000000  <60000000  <70000000  >=70000000
100.00%    0.00%      0.00%      0.00%      0.00%      0.00%      0.00%      0.00%

Para iniciar um calibrate, utilize, por exemplo, a sintaxe:

 chactl calibrate database -db cdbrac -model weekday -timeranges 
'start=2017-10-23 15:41:50,end=2017-10-23  17:38:35'
 

Para monitorar o cluster utilizando o novo modelo criado: chactl monitor cluster –model weekday




Gerenciando o repositório Cluster Health Advisor

O repositório do CHA guarda as informações históricas dos problemas com o cluster, problemas com o banco, e evidencias sobre as métricas relacionadas, além dos modelos criados.

Por padrão, o repositório é configurado para reter dados de 16 targets (nodes ou db instances) por 72 horas. Se o número de targets crescer, a retenção será automaticamente reduzida. Um alerta crítico é gerado quando a retenção estiver inferior à 24 horas.

Para visualizar os detalhes do repositório rode chactl query repository


Para aumentar o tamanho do repositório, utilize: chactl resize repository –entities <N>


Detalhe do repositório com suporte a 32 targets.




Checando o status do Cluster Health Advisor

Utilize os comandos SRVCTL para verificar o status e configuração do CHA.


Ou parar o CHA em um node.




Sobre o ambiente utilizado para esse artigo

Sistema Operacional: Oracle Linux 7.3 UEK 4 Update 4
Banco de Dados: Oracle Enterprise Database Release Update 12.2.0.1.170814
Swingbench 2.5 para Linux


Referências

Autonomous Health Framework User’s Guide -
https://docs.oracle.com/database/122/ATNMS/purpose-of-cluster-health-advisor.htm#ATNMS-GUID-78F409B6-7CB2-4103-9460-4E87F48DCEC2



Rogerio Bacchi Eguchi é um DBA Oracle Sênior com extensa experiência em ambientes OLTP de missão crítica e que empregam as tecnologias da "Oracle Maximum Availability Architecture". Atuou como DBA em empresas como Oracle, UOL, UOLDiveo, PagSeguro e atualmente atua como DBA/DMA na TOTVS. Possui as certificações Oracle OCP 8i, 9i, 10g, 11g, 12c e OCE Exadata. Atua também como SysAdmin/DEVOPS onde é certificado Linux RHCE. Entusiata de novas tecnologias como big data, automações e cloud computing. Compartilha conhecimento no blog reguchi.wordpress.com e twitter @reguchi_br.

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.