sexta-feira, 14 de abril de 2017

Collaborate 17 - Review

Olá pessoal,

Participei do evento Collaborate17, que ocorreu em Las Vegas de 02 à 06/04.

Hotel do Evento:


Credenciamento:




Domingo

 SQL Tunning workshop com Mauro Pagano e Dimas Chbane:



Segunda

Oracle Real Application Clusters 12c Release 2 Best Practices



Transforming Data Management with Oracle Database 12c Release 2





The Best Oracle Database 12c & 12cR2 New Features



Uma das melhores palestras do evento com o Mike Dietrich "Best Practice to Ensure Performance Stability after a Database Upgrade"






Cardinality Feedback: What is it? Friend or Foe?


Oracle ACE Dinner



Terça

Minha sessão foi a primeira da manhã "Moving your Oracle Databases to the Oracle Cloud"




Stop Guessing, Start Analyzing: New Analytic View Features in Oracle Database 12cR2


 Laugh Your Way To Understanding Oracle, Queuing Theory & Performance


Full Table Scan: Friend or Foe? (#IOUGeniusPerformance)


Uma das melhores palestras do evento, com Markus Michalewicz "Under the Hood of Oracle Real Application Clusters (RAC) 12c Release 2"



Quarta

RMAN in Oracle Database 12c - Top New Features


Adapting to Adaptive Plans on 12c



Tips and Best Practices for DBAs (#IOUGeniusPerformance)


OakTable World - Chasing the Optimizer



Quinta

Oracle Maximum Availability Architecture for the Cloud


Innovation, the Oracle Cloud, Big Data and the Internet of Things 


Sexta

Na sexta-feira estive em Dallas, no escritório da Enkitec



Abraço

Alex Zaballa

quarta-feira, 18 de janeiro de 2017

Statistics Preferences - Script

Tabelas:

Select * from DBA_TAB_STAT_PREFS;

SELECT 
  owner, table_name,
  DBMS_STATS.get_prefs(ownname=>owner,tabname=>table_name,pname=>'INCREMENTAL') incremental,
  DBMS_STATS.get_prefs(ownname=>owner,tabname=>table_name,pname=>'GRANULARITY') granularity,
  DBMS_STATS.get_prefs(ownname=>owner,tabname=>table_name,pname=>'STALE_PERCENT') stale_percent,
  DBMS_STATS.get_prefs(ownname=>owner,tabname=>table_name,pname=>'NO_INVALIDATE') no_invalidate,
  DBMS_STATS.get_prefs(ownname=>owner,tabname=>table_name,pname=>'ESTIMATE_PERCENT') estimate_percent,
  DBMS_STATS.get_prefs(ownname=>owner,tabname=>table_name,pname=>'CASCADE') cascade,
  DBMS_STATS.get_prefs(ownname=>owner,tabname=>table_name,pname=>'METHOD_OPT') method_opt
FROM dba_tables
WHERE owner like 'SAN%'
ORDER BY owner, table_name;


Schemas:

SELECT 
  username,
  DBMS_STATS.get_prefs(ownname=>USERNAME,pname=>'INCREMENTAL') incremental,
  DBMS_STATS.get_prefs(ownname=>USERNAME,pname=>'GRANULARITY') granularity,
  DBMS_STATS.get_prefs(ownname=>USERNAME,pname=>'STALE_PERCENT') stale_percent,
  DBMS_STATS.get_prefs(ownname=>USERNAME,pname=>'NO_INVALIDATE') no_invalidate,
  DBMS_STATS.get_prefs(ownname=>USERNAME,pname=>'ESTIMATE_PERCENT') estimate_percent,
  DBMS_STATS.get_prefs(ownname=>USERNAME,pname=>'CASCADE') cascade,
  DBMS_STATS.get_prefs(ownname=>USERNAME,pname=>'METHOD_OPT') method_opt
FROM dba_users
ORDER BY username;



Database:

SELECT 
  DBMS_STATS.get_prefs(pname=>'INCREMENTAL') incremental,
  DBMS_STATS.get_prefs(pname=>'GRANULARITY') granularity,
  DBMS_STATS.get_prefs(pname=>'STALE_PERCENT') publish,
  DBMS_STATS.get_prefs(pname=>'NO_INVALIDATE') no_invalidate,
  DBMS_STATS.get_prefs(pname=>'ESTIMATE_PERCENT') estimate_percent,
  DBMS_STATS.get_prefs(pname=>'CASCADE') cascade,
  DBMS_STATS.get_prefs(pname=>'METHOD_OPT') method_opt
FROM dual;


Diferença entre


SET_GLOBAL_PREFS Procedure


This procedure is used to set the global statistics preferences.



NLS_ENV - DBMS_SCHEDULER ou DBMS_JOB

Olá pessoal,

Hoje um cliente me chamou para relatar uma situação estranha na geração de arquivos via JOB.

Ele relatou que não estava mais gerando datas e valores no formato Brasil e sim no Americano.

Investigando, verifiquei que a coluna NLS_ENV da DBA_JOBS estava diferente.

Cheguei a seguinte nota do Metalink:

The Priority of NLS Parameters Explained (Where To Define NLS Parameters) (Doc ID 241047.1)

E ao "problema":

* DBMS_SCHEDULER or DBMS_JOB store the SESSION values of the SUBMITTING session for each job. This is visible in the NLS_ENV column of DBA_SCHEDULER_JOBS or DBA_JOBS


Abs
Alex Zaballa

sábado, 31 de dezembro de 2016

O meu ano de 2016 na comunidade Oracle

Olá pessoal,

Seguindo a tradição dos outros anos, segue um resumo do meu ano na comunidade Oracle.

Anos anteriores:

  O meu ano de 2015 na comunidade Oracle

O ano de 2016 já começo bem, fui entrevistado pela Oracle Magazine:


Eventos em que participei:

                Fevereiro:  RMOUG Training Days - 2016
                                RMOUG Training Days - 2016 - Fotos
                                Oracle ACE Program Dinner

                Abril: DBA Brasil 1.0

                Junho: Enkitec E4
                             Enkitec E4 - Fotos 
                        Oracle Open World Brasil - 2016
                           Entrevista - Oracle Open World Brasil - 2016

                Julho: GUOB TECH DAY 2016 - OTN TOUR LA

                Agosto: OTN TOUR LA - México
                           OTN TOUR LA - México - Fotos
                        OTN TOUR LA - Guatemala
                           OTN TOUR LA - Guatemala - Fotos
                        OTN TOUR LA - Costa Rica
                           OTN TOUR LA - Costa Rica - Fotos
                           OTN TOUR LA - Costa Rica - Entrevista                    

                Setembro:  Oracle Ace Briefing 2016
                                 Oracle Ace Briefing 2016 - Fotos
                                  Oracle Open World 2016
                                      Oracle Open World 2016 - Fotos

                Novembro: InteropMix 2016 - São Paulo


The Oracle ACE Program Newsletter:

       Fevereiro



       Março



       Maio



       Junho




      Agosto:



     Setembro:





Série de Artigos publicados no OTN  para preparação do OCM 12c:


Parte 1:

Parte 2:


Outros artigos publicados:



Obtive uma ótima pontuação para garantir minha continuidade como Oracle ACE Director:



Passei no OCM 12c:


Accenture Spotlight:



Accenture Operations Newsletter:



Ganhei o melhor presente:




Gostaria de agradecer ao Oracle ACE Programao Oracle OTN e a Enkitec pelas oportunidades.

  • Evento já programado para 2017:
               COLLABORATE 17 - IOUG

Um bom 2017.
Alex Zaballa

sexta-feira, 30 de dezembro de 2016

Oracle DBFS: “fail to connect to database server”

Olá pessoal,

Hoje recebi uma ligação de um cliente que estava com o erro “fail to connect to database server” ao tentar montar o filesystem que acessa o DBFS em uma máquina:



Após verificar se essa string AUX estava correta no tnsnames.ora, se os serviços do banco do DBFS estavam no ar e se outras máquinas estavam conectadas e conseguiam gerar arquivos, tudo parecia ok. Porém o erro ao conectar continuava.

Solicitei que ele tentasse logar utilizando o SQLPLUS e consegui identificar o erro:


A senha do usuário estava para expirar.

Solução:

alter user MEU_SUER identified by MINHA_SENHA;



terça-feira, 27 de dezembro de 2016

A triste batalha entre um EXADATA X5 e a SHARED POOL

Olá pessoal,

Esta semana investiguei um problema em um cliente, onde ocorreu a queda de um dos bancos do Exadata por 2 vezes.

O Exadata em questão é um X5-2 quarter rack.

Essa foi a imagem que recebi da área de monitoramento com o ocorrido:


Apenas uma suspeita gerado no alert.log de uma das instances:



Analisando os principais eventos de contenção dos ultimos dias, encontrei:

Apesar de existirem diversos WAITS de ROW LOCK CONTENTION, resolvi partir direto para o problema de library cache lock, seguindo a pista do erro no alert.log.

Algo que me chamou a atenção, foi o banco ter 65GB como limite mínimo de SHARED POOL, apesar de ser uma base pequena de 700GB:


Usei esse seguinte script para verificar o uso da shared pool.

Para minha surpresa, 98% dos 65GB estavam em uso:



Para confirmar qual sub-pool da shared estava sendo mais utilizado, utilizei este script do Tanel.


Confirmado que é a área responsável por guardar os SQLs.


Dentro do eDB360 existe um script que coleta os SQLs que não estão usando BIND:

WITH
lit AS (
SELECT /*+ MATERIALIZE NO_MERGE */ /* 2a.152 */
       force_matching_signature, COUNT(*) cnt, MIN(sql_id) min_sql_id, MAX(SQL_ID) max_sql_id
  FROM gv$sql
 WHERE force_matching_signature > 0
   AND UPPER(sql_text) NOT LIKE '%EDB360%'
 GROUP BY
       force_matching_signature
HAVING COUNT(*) > 99
)
SELECT /*+ NO_MERGE */ /* 2a.152 */
       DISTINCT lit.cnt, s.force_matching_signature, s.parsing_schema_name owner,
       CASE WHEN o.object_name IS NOT NULL THEN o.object_name||'('||s.program_line#||')' END source,
       s.sql_text
  FROM lit, gv$sql s, dba_objects o
 WHERE s.force_matching_signature = lit.force_matching_signature
   AND s.sql_id = lit.min_sql_id
   AND o.object_id(+) = s.program_id
 ORDER BY
       1 DESC, 2;


Confirmadas minhas primeiras suspeitas, a aplicação não utliza variáveis BIND:


Nesse caso temos 2 alternativas:

 1 - Corrigir a aplicação :)
 2 - Utilizar o cursor_sharing=force (sim, podemos ter problemas de performance)


Como a solução 1 não é rápida, optei pela 2 para resolver emergencialmente o problema.
Para não afetar todo banco, criei uma trigger de logon para alterar o parâmetro em 2 usuários específicos:

CREATE OR REPLACE TRIGGER SYSTEM.LOGIN_SHARED
AFTER LOGON ON DATABASE
BEGIN
  IF USER in ('USUARIO_1','USUARIO_2')  
  THEN
    EXECUTE IMMEDIATE ('ALTER SESSION SET CURSOR_SHARING=''FORCE''');
  END IF;
EXCEPTION
WHEN OTHERS THEN
NULL;
END;

-->
/

Para o USUARIO_1, o problema foi resolvido. Porém para o USUARIO_2, começaram a ocorrer problemas de performance em queries devido a mudança nos planos de execução.

Possíveis soluções:

 1 - Utilizar SQL PLAN BASELINES --> Demorado

 2 - Fazer FLUSH da SHARED POOL de tempos em tempos --> Fora de cogitação

 3 - Criar uma rotina para fazer o FLUSH de SQLs específicos --> Essa opção que eu utilizei


Utilizei como base esse script do Carlos Sierra:


Problema resolvido e o cliente feliz :)

P.S. Lembrei de um artigo que publiquei no GPO :)