segunda-feira, 20 de fevereiro de 2017

Carregando SQL Plans na SPM utilizando o AWR

A alteração do plano de execução de qualquer instrução sql pode ser desencadeada por uma variedade de ações e mudanças, desde a coleta de estatísticas (tabela, índice, schema, etc), mudanças de parâmetros, definição do objeto, criação ou remoção de índices, entre outros. 

Uma solução muito útil para este problema de desempenho resultante da mudança de plano de execução tem sido o SPM (SQL Plan Management).

O SPM foi introduzido na versão 11g cujo proposito é "impedir regressões de desempenho resultantes de mudanças súbitas no plano de execução de uma instrução SQL, fornecendo componentes para capturar, selecionar e desenvolver informações de plano SQL."

Este mecanismo cria uma SQL Plan Baseline, que é um conjunto de planos aceitos para uma instrução SQL.

Os SQL Plan Baselines podem ser carregados de varias formas:

  1. A partir do cursor cache (shared sql area);
  2. Utilizando SQL Tuning Set (STS);
  3. Export e Import usando "Staging table";
  4. Automaticamente.
Veremos mais abaixo como carregar um plano "bom" que não esta mais na shared sql area (cursor cache) mas ainda está presente no AWR.


Neste caso tenho a instrução sql (sql_id = 91jcabsgk4ydx) com problemas de performance pois um plano ruim está sendo selecionado.

Buscando pelos planos atuais deste sql_id temos apenas o plano de hash 1491429885, que no caso é o plano de execução ruim.


SQL> select distinct plan_hash_value from gv$sql where sql_id='91jcabsgk4ydx';

PLAN_HASH_VALUE
---------------
     1491429885

Pesquisando no AWR encontrei outros planos para esta mesma instrução sql, neste caso o plano de hash 1748113394 é o plano "bom".


SQL> select distinct plan_hash_value from dba_hist_sqlstat where sql_id='91jcabsgk4ydx';

PLAN_HASH_VALUE
---------------
     1748113394
     1491429885

Mais a frente irei especificar um conjunto de snapshots onde será buscado e carregado o plano de execução para dentro da STS, desta forma, abaixo já coletei o intervalo de snapshots onde o plano desejado está presente.

SQL> select min(snap_id), max(snap_id), plan_hash_value from dba_hist_sqlstat where sql_id='91jcabsgk4ydx' group by plan_hash_value ;

MIN(SNAP_ID) MAX(SNAP_ID) PLAN_HASH_VALUE
------------ ------------ ---------------
       14912        15006      1748113394
       14895        15008      1491429885

Criando um STS (SQL Tuning Set):

exec dbms_sqltune.create_sqlset(sqlset_name => '91jcabsgk4ydx_load_plan',description => 'load plan');

PL/SQL procedure successfully completed.

Populando STS com os planos do AWR:

declare
cur sys_refcursor;
begin
open cur for
select VALUE(p) from table(
DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY(begin_snap=> 14912, end_snap => 15006, basic_filter =>'sql_id = ''91jcabsgk4ydx''', attribute_list=>'ALL')) p;
DBMS_SQLTUNE.LOAD_SQLSET( sqlset_name => '91jcabsgk4ydx_load_plan', populate_cursor=>cur);
close cur;
end;
/

PL/SQL procedure successfully completed.

Nos parâmetros begin_snap e end_snap insira os dados retornados no comando anterior de min/max snap_id. Na coluna basic_filter é a condição de "pesquisa"/filtro, ou seja, foi inserido sql_id = 91jcabsgk4ydx para capturar todos os planos relacionados a este sql_id.

A coluna attribute_list representa os atributos de retorno os valores possíveis são:

BASIC: todos os atributos (como estatísticas de execução e binds) são retornados, exceto os planos. O contexto de execução é sempre parte do resultado.

TYPICAL: BASIC + SQL plan (sem estatísticas de origem de linha) e sem lista de referência de objeto (padrão).

ALL: todos os atributos, sem excessão.

Lista de nomes de atributos separados por vírgulas, isto permite retornar apenas um subconjunto de atributos SQL: EXECUTION_STATISTICS, SQL_BINDS, SQL_PLAN_STATISTICS

OBS: Caso queria carregar todos os sqls capturados no AWR basta inserir NULL em basic_filter.

Detalhes do STS:


SQL> SELECT NAME,OWNER,CREATED,STATEMENT_COUNT FROM DBA_SQLSET where name='91jcabsgk4ydx_load_plan';

NAME                           OWNER                          CREATED   STATEMENT_COUNT
------------------------------ ------------------------------ --------- ---------------
91jcabsgk4ydx_load_plan        SYS                            17-FEB-17               1

Para verificar os planos do SQL_ID carregados na STS:

SQL> select * from table(dbms_xplan.display_sqlset('91jcabsgk4ydx_load_plan','91jcabsgk4ydx'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL Tuning Set Name: 91jcabsgk4ydx_load_plan
SQL Tuning Set Owner: SYS
SQL_ID: 91jcabsgk4ydx
SQL Text: 
   [...]
--------------------------------------------------------------------------------

Plan hash value: 203381466

----------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |                      |       |       |     5 (100)|          |
|   1 |  SORT GROUP BY                    |                      |     1 |   231 |     5  (20)| 00:00:01 |
|   2 |   FILTER                          |                      |       |       |            |          |
|   3 |    NESTED LOOPS                   |                      |     1 |   231 |     4   (0)| 00:00:01 |
|   4 |     NESTED LOOPS                  |                      |     2 |   231 |     4   (0)| 00:00:01 |
|   5 |      NESTED LOOPS                 |                      |     1 |   156 |     3   (0)| 00:00:01 |
|   6 |       NESTED LOOPS                |                      |     1 |   105 |     2   (0)| 00:00:01 |
|   7 |        TABLE ACCESS BY INDEX ROWID| TAB1                 |     2 |   118 |     1   (0)| 00:00:01 |
|   8 |         INDEX RANGE SCAN          | TAB1_IDX1            |   158 |       |     1   (0)| 00:00:01 |
|   9 |        TABLE ACCESS BY INDEX ROWID| TAB2                 |     1 |    46 |     1   (0)| 00:00:01 |
|  10 |         INDEX UNIQUE SCAN         | TAB2_IDX1            |     1 |       |     1   (0)| 00:00:01 |
|  11 |       TABLE ACCESS BY INDEX ROWID | TAB3                 |     1 |    51 |     1   (0)| 00:00:01 |
|  12 |        INDEX UNIQUE SCAN          | TAB3_PK              |     1 |       |     1   (0)| 00:00:01 |
|  13 |      INDEX RANGE SCAN             | TAB4                 |     2 |       |     1   (0)| 00:00:01 |
|  14 |     TABLE ACCESS BY INDEX ROWID   | TAB4_IDX1            |     1 |    75 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------

Plan hash value: 1748113394

----------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |                      |       |       |     6 (100)|          |
|   1 |  SORT GROUP BY                    |                      |     1 |   232 |     6  (34)| 00:00:01 |
|   2 |   FILTER                          |                      |       |       |            |          |
|   3 |    NESTED LOOPS                   |                      |     1 |   232 |     4   (0)| 00:00:01 |
|   4 |     NESTED LOOPS                  |                      |     2 |   232 |     4   (0)| 00:00:01 |
|   5 |      NESTED LOOPS                 |                      |     1 |   157 |     3   (0)| 00:00:01 |
|   6 |       NESTED LOOPS                |                      |     1 |   105 |     2   (0)| 00:00:01 |
|   7 |        TABLE ACCESS BY INDEX ROWID| TAB2                 |     1 |    46 |     1   (0)| 00:00:01 |
|   8 |         INDEX RANGE SCAN          | TAB2_IDX2            |     1 |       |     1   (0)| 00:00:01 |
|   9 |        TABLE ACCESS BY INDEX ROWID| TAB1                 |     1 |    59 |     1   (0)| 00:00:01 |
|  10 |         INDEX RANGE SCAN          | TAB1_IDX2            |     1 |       |     1   (0)| 00:00:01 |
|  11 |       TABLE ACCESS BY INDEX ROWID | TAB3                 |     1 |    52 |     1   (0)| 00:00:01 |
|  12 |        INDEX UNIQUE SCAN          | TAB3_PK              |     1 |       |     1   (0)| 00:00:01 |
|  13 |      INDEX RANGE SCAN             | TAB4                 |     2 |       |     1   (0)| 00:00:01 |
|  14 |     TABLE ACCESS BY INDEX ROWID   | TAB4_IDX1            |     1 |    75 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------


108 rows selected.

SQL>

A partir dos planos acima, confirmei que a considerada "boa" é a do plano hash = 1748113394

Criando o SQL Baseline a partir do STS deixando o novo plano (1748113394) habilitado e fixado:


set serveroutput on
declare
my_int pls_integer;
begin
my_int := dbms_spm.load_plans_from_sqlset (
sqlset_name => '91jcabsgk4ydx_load_plan',
basic_filter => 'plan_hash_value=''1748113394''',
sqlset_owner => 'SYS',
fixed => 'YES',
enabled => 'YES');
DBMS_OUTPUT.PUT_line(my_int);
end;
/

PL/SQL procedure successfully completed.

A partir de agora quando a instrução SQL for executada o SPB criado será utilizado para forçar o novo plano.

Verificando a instrução em cursor cache podemos observar que já consta na Note: - SQL plan baseline SQL_PLAN_2qz5a7x8r3ppzbd69646e used for this statement


SQL> select * from table (dbms_xplan.display_cursor('91jcabsgk4ydx', 0));

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  91jcabsgk4ydx, child number 0
-------------------------------------

[...]

Plan hash value: 1748113394

----------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |                      |       |       |     6 (100)|          |
|   1 |  SORT GROUP BY                    |                      |     1 |   232 |     6  (34)| 00:00:01 |
|   2 |   FILTER                          |                      |       |       |            |          |
|   3 |    NESTED LOOPS                   |                      |     1 |   232 |     4   (0)| 00:00:01 |
|   4 |     NESTED LOOPS                  |                      |     2 |   232 |     4   (0)| 00:00:01 |
|   5 |      NESTED LOOPS                 |                      |     1 |   157 |     3   (0)| 00:00:01 |
|   6 |       NESTED LOOPS                |                      |     1 |   105 |     2   (0)| 00:00:01 |
|   7 |        TABLE ACCESS BY INDEX ROWID| TAB2                 |     1 |    46 |     1   (0)| 00:00:01 |
|   8 |         INDEX RANGE SCAN          | TAB2_IDX2            |     1 |       |     1   (0)| 00:00:01 |
|   9 |        TABLE ACCESS BY INDEX ROWID| TAB1                 |     1 |    59 |     1   (0)| 00:00:01 |
|  10 |         INDEX RANGE SCAN          | TAB1_IDX2            |     1 |       |     1   (0)| 00:00:01 |
|  11 |       TABLE ACCESS BY INDEX ROWID | TAB3                 |     1 |    52 |     1   (0)| 00:00:01 |
|  12 |        INDEX UNIQUE SCAN          | TAB3_PK              |     1 |       |     1   (0)| 00:00:01 |
|  13 |      INDEX RANGE SCAN             | TAB4                 |     2 |       |     1   (0)| 00:00:01 |
|  14 |     TABLE ACCESS BY INDEX ROWID   | TAB4_IDX1            |     1 |    75 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

[...]

Note
-----
   - SQL plan baseline SQL_PLAN_2qz5a7x8r3ppzbd69646e used for this statement


70 rows selected.

Referências:

http://docs.oracle.com/cd/E25178_01/server.1111/e16638/optplanmgmt.htm
https://aprakash.wordpress.com/2012/07/05/loading-sql-plan-into-spm-using-awr/

Mais informações →

quarta-feira, 1 de fevereiro de 2017

System Statistics – modo “Exadata”

Adicionado nas estatísticas de sistema, temos agora o modo "Exadata". Seu objetivo é auxiliar com maior eficiência a coleta de informações sobre o sistema de armazenamento na plataforma Exadata. 

Não coletar as estatísticas de sistema específica para Exadata pode levar a planos otimizadores menos eficientes. 

Para verificar se a estatística já foi coletada alguma vez, execute:

SQL> select pname, PVAL1 from aux_stats$ where pname='MBRC';

PNAME                               PVAL1
------------------------------ ----------
MBRC

Estando o retorno do PVAL1 nulo, as estatísticas especificas do Exadata ainda não foram coletadas.

Para coletar as estatísticas especificas para Exadata:

SQL> exec dbms_stats.gather_system_stats('EXADATA');

PL/SQL procedure successfully completed.
Agora:
SQL> SELECT PNAME, PVAL1 FROM SYS.AUX_STATS$ WHERE SNAME = 'SYSSTATS_MAIN';

PNAME                               PVAL1
------------------------------ ----------
CPUSPEED
CPUSPEEDNW                           2918
IOSEEKTIM                               7
IOTFRSPEED                           4096
MAXTHR
MBRC                                  128
MREADTIM
SLAVETHR
SREADTIM

9 rows selected.

Machine type:     X2-2(4170), X2-2, X2-8, X3-2, X3-8, X4-2
Exadata version: 11.2.x +
Oracle version:   Pelo menos 11.2.0.2 BP18 ou 11.2.0.3 BP8

Referência: 
Oracle Sun Database Machine Setup/Configuration Best Practices [ID 1274318.1]
Mais informações →

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 →
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