quinta-feira, 10 de novembro de 2016

ILOM - Erros no "Launch Remote Console"

Recentemente precisei acessar a ILOM (Integrated Lights Out Manager) de um ODA para iniciar a console remota - "Launch Remote Console", contudo veio o primeiro erro:

java.lang.SecurityException: Missing required Permissions manifest attribute in main jar


Pesquisando um pouco encontrei a solução para este erro, conforme passos a seguir:


  • Acessar painel de controle;
  • "Encontrar" o Java e clicar sobre para abrir o Painel de Controle Java (para facilitar a localização escreva java na caixa de pesquisa);

  • Acessar a aba Segurança;
  • Clicar sobre "Editar Lista de Sites..."

  • Clicar sobre "Adicionar";

  • Inserir o IP e porta da ILOM conforme dados do erro;
  • OK; OK ..

Feito isto fui abrir novamente a console remota da ILOM.

Agora a console abriu com sucesso, mas como podemos ver abaixo, tive outro erro sendo reportado:

No appropriate protocol (protocol is disabledor cipher suites are inappropriate)


Fazendo mais algumas pesquisas, identifiquei que na CVE-2014-3566 - "SSL V3.0 "Poodle" Vulnerability" o algoritmo SSLv3, por padrão, foi desabilitado a partir da JDK 8u31. Nas versões 7u75 e 6u91 também foram ajustadas.

Conforme nota da versão, habilitei novamente o SSLv3 editando o arquivo <JRE_HOME>/lib/security/java.security

Como estou utilizando um sistema operacional Windows, o arquivo foi localizado em "C:\Program Files\Java\jre1.8.0_91\lib\security" conforme imagem abaixo.


Ao abrir o arquivo com o editor bloco de notas, localizei a entrada jdk.tls.disabledAlgorithms, comentei a linha e salvei o arquivo. 

OBS: retirando apenas a entrada SSLv3 não funcionou comigo

de:

jdk.tls.disabledAlgorithms= SSLv3, RC4, MD5withRSA, DH keySize < 768

para:

#jdk.tls.disabledAlgorithms= SSLv3, RC4, MD5withRSA, DH keySize < 768

Mesmo com o ajuste, ao abrir a console fui submetido a um novo erro:

java.security.cert.CertificateException: Certificates does not conform to algorithm constraints


Voltando as pesquisas... encontrei um novo parâmetro, também dentro do java.security 

Abri novamente o arquivo java.security, localizei o jdk.certpath.disabledAlgorithms e comentei a linha.

de:

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

para:

#jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

Tentando novamente abrir a console remota.. 



Bingo!

Console remota abrindo com sucesso, basta inserir o usuário e senha.

Espero ter ajudado!

Referências:

http://stackoverflow.com/questions/21404830/securityexception-during-executing-jnlp-file-missing-required-permissions-manif
http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html
http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html
http://www.oracle.com/technetwork/java/javase/8u31-relnotes-2389094.html
https://www.richardnichols.net/2012/08/arrrggh-java-security-cert-certificateexception-certificates-does-not-conform-to-algorithm-constraints/
Mais informações →

quinta-feira, 13 de outubro de 2016

Formatando um bloco corrompido que não faz parte de um segmento

Durante a execução de um backup full database(RMAN) obtive o erro ORA-19566 informando a identificação de blocos corrompidos em um datafile. 

ORA-19566: exceeded limit of 0 corrupt blocks for file /oradata01/oracle/orcl/indices/TBS_INDICES40.dbf

Abrindo o alertlog do banco de dados temos um detalhamento do ocorrido, onde aponta inclusive qual objeto utiliza este bloco.

Mon Oct 03 10:35:02 BRT 2016
Hex dump of (file 439, block 299712) in trace file /home/oracle/home/admin/orcl/udump/orcl_ora_25903.trc
Corrupt block relative dba: 0x6dc492c0 (file 439, block 299712)
Fractured block found during buffer read
Data in bad block:
 type: 6 format: 2 rdba: 0x6dc492c0
 last change scn: 0x0040.47e5f156 seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00c351d5
 check value in block header: 0xd7cb
 computed block checksum: 0x9ae3
Reread of rdba: 0x6dc492c0 (file 439, block 299712) found same corrupted data
Mon Oct 03 10:35:02 BRT 2016
Corrupt Block Found
         TSN = 25, TSNAME = TBS_INDICES
         RFN = 439, BLK = 299712, RDBA = 1841599168
         OBJN = 60476, OBJD = 60476, OBJECT = IDX_TEST_FK_I, SUBOBJECT =
         SEGMENT OWNER = PRD, SEGMENT TYPE = Index Segment
Após realizar o rebuild do indice, executei um DBV (DBVERIFY) sobre o arquivo de dados e além do bloco 299712, foram identificados mais 2 blocos corrompidos (299713 e 299714)

Para asber mais sobre o DBV, clique aqui.

Banco=orcl-> dbv file=/oradata01/oracle/orcl/indices/TBS_INDICES40.dbf

DBVERIFY: Release 10.2.0.5.0 - Production on Tue Oct 4 08:29:29 2016

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

DBVERIFY - Verification starting : FILE = /oradata01/oracle/orcl/indices/TBS_INDICES40.dbf
Page 299712 is influx - most likely media corrupt
Corrupt block relative dba: 0x6dc492c0 (file 439, block 299712)
Fractured block found during dbv:
Data in bad block:
 type: 6 format: 2 rdba: 0x6dc492c0
 last change scn: 0x0040.47e5f156 seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00c351d5
 check value in block header: 0xd7cb
 computed block checksum: 0x9ae3

Page 299713 is marked corrupt
Corrupt block relative dba: 0x6dc492c1 (file 439, block 299713)
Bad header found during dbv:
Data in bad block:
 type: 231 format: 2 rdba: 0x001bfcf8
 last change scn: 0x006c.3710b7ec seq: 0xb5 flg: 0x1c
 spare1: 0x19 spare2: 0x0 spare3: 0x65
 consistency value in tail: 0x3f8303ce
 check value in block header: 0x3903
 computed block checksum: 0x0

Page 299714 is marked corrupt
Corrupt block relative dba: 0x6dc492c2 (file 439, block 299714)
Bad header found during dbv:
Data in bad block:
 type: 231 format: 2 rdba: 0x001bfd08
 last change scn: 0x0048.3710b7ec seq: 0x6d flg: 0x6c
 spare1: 0x19 spare2: 0x0 spare3: 0x5301
 consistency value in tail: 0x94410601
 check value in block header: 0x1389
 computed block checksum: 0x4162



DBVERIFY - Verification complete

Total Pages Examined         : 408832
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 405595
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 668
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 2566
Total Pages Marked Corrupt   : 3
Total Pages Influx           : 1
Highest block SCN            : 1749727541 (64.1749727541)
Voltei na base de dados e verifiquei se havia mais algum segmento utilizando estes blocos:

SQL> SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = 439 and 299712 between block_id AND block_id + blocks - 1 ;

no rows selected

SQL> SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = 439 and 299713 between block_id AND block_id + blocks - 1 ;

no rows selected

SQL> SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = 439 and 299714 between block_id AND block_id + blocks - 1 ;

no rows selected

Nenhum segmento identificado nestes blocos!

Pois bem, já que não temos nenhum segmento, precisamos formatar este blocos.

Primeiramente identificamos a qual tablespace pertence o arquivo de dados:

SQL>  select tablespace_name from dba_data_files where file_name='/oradata01/oracle/orcl/indices/TBS_INDICES40.dbf';

TABLESPACE_NAME
------------------------------
TBS_INDICES

Agora criamos uma tabela abaixo desta tablespace, como no exemplo a seguir:

create table prd.fix_corrupt ( 
n number, 
c varchar2(4000) 
) PCTFREE 95 tablespace TBS_INDICES;

Utilizei PCTFREE 95 para que posteriormente seja necessário a inserção de menos registros até chegarmos ao bloco corrompido. 

Criado a tabela, vamos criar uma trigger para abortar o processo se inserção quando o bloco corrompido for utilizado e nos informar em tela.

CREATE OR REPLACE TRIGGER corrupt_trigger 
  AFTER INSERT ON prd.fix_corrupt
  REFERENCING OLD AS p_old NEW AS new_p 
  FOR EACH ROW 
DECLARE 
  corrupt EXCEPTION; 
BEGIN 
  IF (dbms_rowid.rowid_block_number(:new_p.rowid)=299712)
 and (dbms_rowid.rowid_relative_fno(:new_p.rowid)=439) THEN 
     RAISE corrupt; 
  END IF; 
EXCEPTION 
  WHEN corrupt THEN 
     RAISE_APPLICATION_ERROR(-20000, 'Corrupt block has been formatted'); 
END; 
/

Na trigger informei rowid_relative_fno(:new_p.rowid)=439 que é meu file_id e o dbms_rowid.rowid_block_number(:new_p.rowid)=299712 que é meu bloco corrompido.

O próximo passo é identificar o tamanho do extent corrompido para que possamos alocá-lo, desta forma realizamos a seguinte consulta na dba_free_space informando o file_id e o numero do bloco, no meu caso 299712.

SQL> Select BYTES from dba_free_space where file_id=439 and 299712 between block_id and block_id + blocks -1;

     BYTES
----------
  67108864

Neste caso é 64K (67108864/1024/1024), assim é possivel alocar o extent da seguinte forma:

alter table prd.fix_corrupt
allocate extent (DATAFILE '/oradata01/oracle/orcl/indices/TBS_INDICES40.dbf' SIZE 64K);


Como não sabemos se existem muitos extents de 64K livres no datafile, podemos utilizar o seguinte loop para alocar os extents:

**Detalhe** 

Antes de executar o comando verificar o maxsize do datafile, ou seja, qual o tamanho maximo que o datafile pode atingir, pois se todos os extents lives tiverem o mesmo tamanho ele pode crescer o datafile até chegar a este limite.

SQL> select bytes/1024/1024, maxbytes/1024/1024 from dba_data_files where file_name='/oradata01/oracle/orcl/indices/TBS_INDICES40.dbf';

BYTES/1024/1024 MAXBYTES/1024/1024
--------------- ------------------
           3194               3500

Meu datafile neste momento tem 3.194 MB e pode chegar até 3.500 MB Executando o loop para alocar os extents:

SQL> BEGIN
for i in 1..1000000 loop
EXECUTE IMMEDIATE 'alter table prd.fix_corrupt allocate extent (DATAFILE '||'''/oradata01/oracle/orcl/indices/TBS_INDICES40.dbf''' ||'SIZE 64K) ';
end loop;
end ;
/  2    3    4    5    6
BEGIN
*
ERROR at line 1:
ORA-01653: unable to extend table PRD.FIX_CORRUPT by 128 in tablespace
TBS_INDICES
ORA-06512: at line 3

Como podemos ver acima ele alocou extents até estourar o datafile, vamos ver agora o tamanho.

SQL> select bytes/1024/1024, maxbytes/1024/1024 from dba_data_files where file_name='/oradata01/oracle/orcl/indices/TBS_INDICES40.dbf';

BYTES/1024/1024 MAXBYTES/1024/1024
--------------- ------------------
           3500               3500

Como ele estava com maxsize de 3500MB o datafile parou de crescer quando chegou a este valor, se ele fosse de 30G, por exemplo, possivelmente ele iria alocar toda esta área o que não seria necessário.. sempre observar este fator antes de executar o loop! se for necessário reduzir o maxsize e após as alocações voltar o valor antigo. 

Agora vamos verificar se os blocos estão sendo utilizados pela tabela criada:

SQL> set lines 200
SQL> col segment_name for a70
SQL> select segment_name, segment_type, owner from dba_extents where file_id = 439 and 299712 between block_id and block_id + blocks -1;

SEGMENT_NAME                                                           SEGMENT_TYPE       OWNER
---------------------------------------------------------------------- ------------------ ------------------------------
FIX_CORRUPT                                                            TABLE              PRD

SEGMENT_NAME                                                           SEGMENT_TYPE       OWNER
---------------------------------------------------------------------- ------------------ ------------------------------
FIX_CORRUPT                                                            TABLE              PRD

SQL> select segment_name, segment_type, owner from dba_extents where file_id = 439 and 299714 between block_id and block_id + blocks -1;

SEGMENT_NAME                                                           SEGMENT_TYPE       OWNER
---------------------------------------------------------------------- ------------------ ------------------------------
FIX_CORRUPT                                                            TABLE              PRD

Visto que os blocos listados como corrompidos estão sendo alocados pela tabela criada, vamos inserir registros até que o bloco seja preenchido e formatado. Para isto iremos utilizar um loop de inserção até que a mensagem gerada pela trigger seja exibida na tela:


Begin
  FOR i IN 1..1000000000 loop
    for j IN 1..1000 loop
      Insert into prd.fix_corrupt VALUES(i,'x');
    end loop;
    commit;
  END LOOP;
END; 
/

Begin
*
ERROR at line 1:
ORA-20000: Corrupt block has been formatted
ORA-06512: at "SYS.CORRUPT_TRIGGER", line 10
ORA-04088: error during execution of trigger 'SYS.CORRUPT_TRIGGER'
ORA-06512: at line 4

Agora executamos um novo DBV para verificar se todos os blocos foram formatados:

Banco=orcl-> dbv file=/oradata01/oracle/orcl/indices/TBS_INDICES40.dbf

DBVERIFY: Release 10.2.0.5.0 - Production on Tue Oct 4 09:31:26 2016

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

DBVERIFY - Verification starting : FILE = /oradata01/oracle/orcl/indices/TBS_INDICES40.dbf


DBVERIFY - Verification complete

Total Pages Examined         : 448000
Total Pages Processed (Data) : 80471
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 358990
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 1068
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 7471
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 1758325239 (64.1758325239)
Banco=orcl->

Estando o valor de "Total Pages Marked Corrupt" = 0 ficou tudo OK, caso ele ainda indique a presença de blocos corrompidos e sem segmentos basta recriar a trigger informando o novo bloco, reexecutar o insert e ao final o DBV até que o valor de blocos marcados como corrompidos seja 0.

Ao termino do processo remover a tabela criada:

SQL> drop table prd.fix_corrupt;

Table dropped.

Referência: 
https://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmvalid.htm
Mais informações →

sexta-feira, 30 de setembro de 2016

STATSPACK lento

Após implementar o statspack, constatei que o job de coleta(snap) estava extremamente lento, estava a mais de 2 horas executando uma operação de insert na STATS$SQL_PLAN (sql_id = d2tjms4f6tt9v). 

Encontrei no MOS (My Oracle Support) a Doc ID 2182680.1 (Statspack Running Slow on 11g Databases Due To Slow Statement 'Insert Into Stat$Sql_Plan...'), porém a mesma é relacionada ao 11g meu ambiente era 10g... 

Na Doc existe um script com modificações na perfstat.STATSPACK, tentei compilá-lo porém apontava para objetos que não existem na versão 10g, desta forma precisei voltar a DDL anterior. 

Buscando dentro do próprio script da fornecido na Doc é possivel observar que na instrução de INSERT INTO STAT$SQL_PLAN, mais especificamente na subquery, existe uma modificação:

--Rem   Modified hint /*+ ordered use_nl(s) use_nl(sp.p) */ 
            select  /*+ no_merge(new_plan) leading(new_plan s sp) use_nl(s) use_nl(sp) */ 


Abri a perfstat.STATSPACK original, busquei pela linha " select /*+ ordered use_nl(s) use_nl(sp.p) */ " e realizei o ajuste das hinsts conforme sugestão da documentação. 

Bingo!! processo executando rapidamente. 

Para quem não conhece, o statspack é um conjunto de monitorização de desempenho e utilitários de relatórios fornecidos pela Oracle desde a versão 8i, é semelhante ao AWR contudo não requer licença, é free!
Mais informações →

segunda-feira, 25 de julho de 2016

Problemas no startup do Oracle agent 12c: 'Target Interaction Manager failed at Startup java.lang.OutOfMemoryError: Java heap space' - gcagent_errors.log

Na tentativa de iniciar o agent do Oracle Enterprise Manager Coud Control em um servidor me deparei com alguns alertas informando estouro de memória do Java "OutOfMemoryError". Realizei o aumento de memória através do parâmetro agentJavaDefines encontrado dentro do arquivo de configurações $AGENT_HOME/sysman/configemd.properties, contudo o problema persistiu. 

Buscando no MOS encontrei a solução via Doc ID 1902124.1 - "EM12c: emctl start agent Fails With 'Target Interaction Manager failed at Startup java.lang.OutOfMemoryError: Java heap space' reported in gcagent_errors.log"

Abaixo visão do problema e solução.

Tentativa de startup (falha):

srvtst-banco=orcl-> $AGENT_HOME/emctl start agent
Oracle Enterprise Manager Cloud Control 12c Release 5
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Starting agent .............................................. failed.
Fatal agent error: State Manager failed at Startup
Fatal agent error: State Manager failed at Startup
Fatal agent error: State Manager failed at Startup
EMAgent is Thrashing. Exiting watchdog
Consult emctl.log and emagent.nohup in: /u01/app/oracle/agent/agent_inst/sysman/log

Verificando log1:

srvtst-banco=orcl-> vi /u01/app/oracle/agent/agent_inst/sysman/log/emagent.nohup

2016-07-02 14:56:02,661 [1:main] WARN - Missing filename for log handler 'opsscfg'
Agent is going down due to an OutOfMemoryError

Verificando log2:
srvtst-banco=orcl-> vi /u01/app/oracle/agent/agent_inst/sysman/log/gcagent.log

2016-07-02 14:56:16,299 [1:main] FATAL - Fatal error: Target Interaction Manager failed at Startup
java.lang.OutOfMemoryError: Java heap space

Executando procedimento do Doc ID 1902124.1 

1. Parando todos os processos do agent:

$AGENT_HOME/bin/emctl stop agent
ps -ef | grep java | grep 'diretório do agent'
ps -ef | grep perl

Finalize qualquer processo JAVA / PERL ativo no diretório do Oracle agent (AGENT_HOME)

kill -9  numero_do_processo

2. Movendo arquivos antigos para um novo diretório:

srvtst-banco=orcl-> mv $AGENT_HOME/sysman/emd/state/* /orabackup/bkp_cloud/

3. Executando o "clearstate agent"

srvtst-banco=orcl-> $AGENT_HOME/bin/emctl clearstate agent
Oracle Enterprise Manager Cloud Control 12c Release 5
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
EMD clearstate completed successfully


NOTA: O agent mantém internamente informações e status dos componentes que ele monitora, afim de evitar um tráfego de rede desnecessário junto ao OMS, contudo se ocorrer alguma mudança no alvo monitorado o agent inicia o upload das informações. O comando clearstate agent obriga o agente a realizar uma nova leitura de cada componentes e reenvia-las ao OMS.

Segundo a DOC, este comando deve ser executado apenas quando o suporte da Oracle recomenda.

4. Fazendo backup do arquivo de parâmetros e aumentando a memória Java:

srvtst-banco=orcl-> cd $AGENT_HOME/sysman/config
srvtst-banco=orcl-> cp emd.properties emd.properties.bkp

atual:
#
# These are the optional Java flags for the agent
#
agentJavaDefines=-Xmx128M -XX:MaxPermSize=96M

para:

#
# These are the optional Java flags for the agent
#
agentJavaDefines=-Xmx512M -XX:MaxPermSize=96M

* alterado o valor do -Xmx de 128M para 512M

5. Iniciando novamente o agent:

srvtst-banco=orcl-> $AGENT_HOME/bin/emctl start agent
Oracle Enterprise Manager Cloud Control 12c Release 5
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Starting agent ........................... started.
srvtst-banco=orcl-> $AGENT_HOME/bin/emctl status agent
Oracle Enterprise Manager Cloud Control 12c Release 5
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
Agent Version          : 12.1.0.5.0
OMS Version            : 12.1.0.5.0
Protocol Version       : 12.1.0.1.0
Agent Home             : /u01/app/oracle/agent/agent_inst
Agent Log Directory    : /u01/app/oracle/agent/agent_inst/sysman/log
Agent Binaries         : /u01/app/oracle/agent/core/12.1.0.5.0
Agent Process ID       : 18183
Parent Process ID      : 18003
Agent URL              : https://srvtst:3872/emd/main/
Local Agent URL in NAT : https://srvtst:3872/emd/main/
Repository URL         : https://srvtst:4900/empbs/upload
Started at             : 2016-07-02 15:02:31
Started by user        : oracle
Operating System       : Linux version 2.6.39-400.126.1.el5uek (amd64)
Last Reload            : (none)
Last successful upload                       : 2016-07-02 15:03:01
Last attempted upload                        : 2016-07-02 15:03:01
Total Megabytes of XML files uploaded so far : 0.41
Number of XML files pending upload           : 0
Size of XML files pending upload(MB)         : 0
Available disk space on upload filesystem    : 48.47%
Collection Status                            : Collections enabled
Heartbeat Status                             : Ok
Last attempted heartbeat to OMS              : 2016-07-02 15:02:52
Last successful heartbeat to OMS             : 2016-07-02 15:02:52
Next scheduled heartbeat to OMS              : 2016-07-02 15:03:53

---------------------------------------------------------------
Agent is Running and Ready
srvtst-banco=orcl->


Espero ter ajudado.!
Mais informações →

sábado, 9 de julho de 2016

Monitorando as baterias no Exadata


As controladoras de disco no Exadata Storage e servidores de banco de dados possuem uma bateria que permite a utilização de um cache de gravação, seu proposito é acelerar o desempenho de operações de escrita uma vez que os blocos são mantidos inicialmente em cache e apenas escritos em disco quando o cache estiver cheio ou uma requisição de escrita exigida. (WriteBack) 

Se a carga da bateria se degrada de tal forma que já não é mais possivel garantir a proteção dos dados em cache para uma perda de energia de 48 horas ou superior, então o cache de gravação é "desativado" e a controladora de disco passa a realizar além das gravações em cache as gravações diretas no disco o que acaba prejudicando o desempenho/tempo total de gravação. (WriteThrough)

[root@db01 ~]# /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -LALL -aALL | grep "Cache Policy" | head -n 2
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU

O Exadata Storage Server gera um alerta quando a capacidade de carga da bateria é insuficiente ou quando a temperatura é alta, e quando a bateria deve ser substituída. 

A capacidade de carga da bateria se degrada ao longo do tempo e sua expectativa de vida é proporcional a temperatura de funcionamento. 

A tabela a seguir demonstra a expectativa de vida da bateria.



A temperatura da bateria pode ser verifica atraves do seguinte comando:

[root@db01 ~]# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep BatteryType; /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep -i temper
BatteryType: iBBU08
Temperature: 23 C
  Temperature                             : OK

Em nota a Oracle indica que se a temperatura for maior ou igual a 55 graus Celsius, deve ser determinado a causa e corrigido o problema. Para monitorarmos a capacidade da bateria utilizamos o seguinte comando:

[root@db01 ~]# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | egrep  "Full Charge|Max Error" | sort
  Full Charge Capacity: 1324 mAh
  Max Error: 0 %

Uma ação proativa de troca da bateria pode ser realizada quando a capacidade (Full Charge Capacity) for menor que 800 mAh e a quantidade máxima de erros (Max Error) for inferior a 10%. 

Realize um substituição imediata de qualquer bateria onde a capacidade for inferior a 674 mAh ou a quantidade máxima de erros for superior a 10%. 

Podemos filtrar ainda por "Battery Replacement required" para saber se a troca é necessária ou não.

[root@db01 ~]# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep "Battery Replacement required"
  Battery Replacement required            : No

Para visualizar todas as informações:

[root@db01 ~]# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0

BBU status for Adapter: 0

BatteryType: iBBU08
Voltage: 3827 mV
Current: 0 mA
Temperature: 23 C
Battery State: Optimal
Design Mode  : 48+ Hrs retention with a non-transparent learn cycle and moderate service life.

BBU Firmware Status:

  Charging Status              : None
  Voltage                                 : OK
  Temperature                             : OK
  Learn Cycle Requested                   : No
  Learn Cycle Active                      : No
  Learn Cycle Status                      : OK
  Learn Cycle Timeout                     : No
  I2c Errors Detected                     : No
  Battery Pack Missing                    : No
  Battery Replacement required            : No
  Remaining Capacity Low                  : No
  Periodic Learn Required                 : No
  Transparent Learn                       : No
  No space to cache offload               : No
  Pack is about to fail & should be replaced : No
  Cache Offload premium feature required  : No
  Module microcode update required        : No

BBU GasGauge Status: 0x0180
  Relative State of Charge: 58 %
  Charger System State: 1
  Charger System Ctrl: 0
  Charging current: 0 mA
  Absolute state of charge: 51 %
  Max Error: 0 %
  Battery backup charge time : 48 hours +

BBU Capacity Info for Adapter: 0

  Relative State of Charge: 58 %
  Absolute State of charge: 51 %
  Remaining Capacity: 765 mAh
  Full Charge Capacity: 1324 mAh
  Run time to empty: Battery is not being charged.
  Average time to empty: 1 Hour, 32 Min.
  Estimated Time to full recharge: Battery is not being charged.
  Cycle Count: 1

BBU Design Info for Adapter: 0

  Date of Manufacture: 01/21, 2014
  Design Capacity: 1500 mAh
  Design Voltage: 4100 mV
  Specification Info: 0
  Serial Number: 3384
  Pack Stat Configuration: 0x0000
  Manufacture Name: LS36691
  Firmware Version   :
  Device Name: bq27541
  Device Chemistry: LION
  Battery FRU: N/A
  Transparent Learn = 0
  App Data = 0

BBU Properties for Adapter: 0

  Auto Learn Period: 28 Days
  Next Learn time: None  Learn Delay Interval:1 Hours
  Auto-Learn Mode: Disabled
  BBU Mode = 7

Exit Code: 0x00

Replacing Batteries in Disk Controllers: 

If the battery charge capacity in the disk controllers falls below the minimum threshold, then Oracle will replace the failed batteries at no extra charge, if the system is covered either by the Oracle Premier Support for Systems or occurs during the warranty period. For customers with Premier Support for Systems, Oracle attempts to proactively replace the batteries in Oracle Exadata Rack before the end of the estimated lifetime, on a best efforts basis.

Referência:
http://docs.oracle.com/cd/E50790_01/doc/doc.121/e51951/app_fru.htm#DBMMN21578
Mais informações →

terça-feira, 16 de fevereiro de 2016

Removendo TAGs RTF no Oracle

O RTF (Rich Text Format) ou "Formato Rico de Texto" é um formato de arquivo de documento desenvolvido e de propriedade da Microsoft para intercâmbio de documentos entre diversas plataformas. Sua base consiste em um formato de texto simples permitindo que a maioria dos processadores de texto sejam capazes de ler e escrever documentos RTF. 

Embora legível(human-readable), visualizar as TAGs RTF quando utilizamos este tipo de documento pode gerar certo desconforto ou mesmo uma grande poluição visual.

Muitas ferramentas disponíveis na internet permitem uma "leitura limpa" do formato (sem as tags), e/ou mesmo sua conversão para outros tipos de formatos, como doc, pdf, etc. mas, recuperar um RTF diretamente no banco de dados Oracle sem as TAGs também é possível.
--criando uma tabela exemplo com RTF
SQL> CREATE TABLE EXEMPLO_RTF
  AS
  SELECT '{\rtf1\ansi\deff0{\fonttbl{\f0\fnil Arial;}{\f1\fnil\fcharset0 Arial;}{\f2\fnil MS Sans Serif;}}
{\colortbl ;\red0\green0\blue0;\red0\green0\blue128;}
\viewkind4\uc1\pard\cf1\lang1046\f0\fs20 Teste RTF ...........................XX
\par XXXXXX - TESTE RTF - XXXXXX
\par 
\par 
\par 
\par Isto é um teste no formato RTF
\c1.\f0 
\par \cf2\f2\fs16 
\par \cf1\f0\fs20  
\par }' AS texto_rtf
    FROM DUAL;

Table created.
--criando a package rtf que executa a chamada do java rtf
SQL> CREATE OR REPLACE PACKAGE rtf
  IS
      PROCEDURE convertToText ( rtf_in IN VARCHAR2, plain_text OUT VARCHAR2 )
      IS
         language java
         name 'rtf.convertToText( java.lang.String, java.lang.String[] )';

      FUNCTION to_text ( rtf_in IN VARCHAR2 )
      RETURN VARCHAR2
      IS
         language java
         name 'rtf.to_text( java.lang.String ) return java.lang.String';

  END rtf;
  /

Package created.
--criando o rtf java
SQL> CREATE OR REPLACE AND COMPILE
JAVA SOURCE NAMED "rtf"
AS
import javax.swing.text.BadLocationException;
import javax.swing.text.Document;
import javax.swing.text.rtf.RTFEditorKit;
import java.io.*;

public class rtf extends Object
{
   public static void convertToText( java.lang.String p_in,
                                     java.lang.String[] p_out )
   throws IOException, BadLocationException
   {
      // test for null inputs to avoid java.lang.NullPointerException when input is null
      if ( p_in != null )
      { RTFEditorKit kit = new RTFEditorKit();
        Document doc = kit.createDefaultDocument();
        kit.read(new StringReader(p_in), doc, 0);
        p_out[0] = doc.getText(0, doc.getLength());
      }
      else p_out[0] = null;
   }

   public static String to_text(String p_in)
   throws IOException, BadLocationException
   {
      // test for null inputs to avoid java.lang.NullPointerException when input is null
      if (p_in != null)
      { RTFEditorKit kit = new RTFEditorKit();
        Document doc = kit.createDefaultDocument();
        kit.read(new StringReader(p_in), doc, 0);
        return doc.getText(0, doc.getLength());
      }
      else return null;
   }
}
/

Java created.
--exemplo de chamada1
SQL> SELECT rtf.to_text( texto_rtf ) AS TEXTO
  2  FROM EXEMPLO_RTF;

TEXTO
--------------------------------------------------------------------------------
Teste RTF ...........................XX
XXXXXX - TESTE RTF - XXXXXX



Isto é um teste no formato RTF.




--exemplo de chamada2
SQL> set lines 200
SQL> set serveroutput on
SQL> DECLARE
   l_text_out VARCHAR2(4000);
BEGIN
     rtf.convertToText
      (
       '{\rtf1\ansi\deff0{\fonttbl{\f0\fnil Arial;}{\f1\fnil\fcharset0 Arial;}{\f2\fnil MS Sans Serif;}}
{\colortbl ;\red0\green0\blue0;\red0\green0\blue128;}
\viewkind4\uc1\pard\cf1\lang1046\f0\fs20 Teste RTF ...........................XX
\par XXXXXX - TESTE RTF - XXXXXX
\par 
\par 
\par 
\par Isto é um teste no formato RTF
\c1.\f0 
\par \cf2\f2\fs16 
\par \cf1\f0\fs20  
\par }
'
       , l_text_out
      );

    DBMS_OUTPUT.PUT_LINE( l_text_out );

END;
/
Teste RTF ...........................XX
XXXXXX - TESTE RTF - XXXXXX



Isto é um teste no formato RTF.




PL/SQL procedure successfully completed.

Referencia:
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:25695084847068
Mais informações →

segunda-feira, 28 de dezembro de 2015

Postagens mais antigas Página inicial

Translate

#Oracle

#Oracle
Disclaimer: The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

#Blog reconhecido

Marcadores

Postagens populares