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 :)



segunda-feira, 14 de novembro de 2016

InteropMix 2016 - São Paulo

Olá pessoal,

No próximo sábado (19/11/2016) irei palestrar no evento InteropMix 2016 sobre Oracle Database 12c Release 2.


O evento será realizado na
Faculdade BandTec
Rua Estela, 268 | São Paulo - SP | Tel: (11) 5574-6844



sábado, 27 de agosto de 2016

Migrando Informix 11.70 para Oracle 12c

Olá pessoal,

Estive trabalhando em uma proposta de migração de Informix para Oracle e vou compartilhar o caminho das pedras.

Banco de Origem:

IBM Informix Dynamic Server Version 11.70.FC5
5TB
7.000 Tabelas
Média de 30 colunas por tabela

Banco de Destino:

Oracle Database Enterprise Edition 12.1.0.2


Algumas opções para migração:

1 - Usar ferramentas Informix para gerar arquivos e depois usar o SQL*Loader ou external tables: viável, porém extremamente trabalhoso para o elevado número de tabelas.

2 - Oracle Database Gateways: Requer licença adicional.

3 - SQL Developer's migration tools: Não suporta o Informix 11.70

4 - Oracle Migration Workbench : Não suporta o Informix 11.70

5 - Criar uma ferramenta para fazer a migração: Custo elevado e a demanda não justifica.

6 - Comprar uma ferramenta pronta.


Minha primeira opção foi em testar uma ferramenta pronta e escolhi duas:

http://www.sqlines.com/informix-to-oracle
http://www.ispirer.com/products/informix-to-oracle-migration

A que eu mais gostei, foi a SQLines Data. Porém tive alguns percalços com relação a versão do windows, drivers odbc e oracle client.

A ferramenta da Ispirer funciona bem, mas um ponto negativo é que ela gera um arquivo texto e depois importa para o Oracle. Tudo de forma automatizada, mas poderia ter a opção de fazer isso via insert direto.


Preparando o ambiente para os testes:

Criei 2 VMs, uma com Windows 7 - 32 bits (Sim, 32 bits, pois foi a única forma da SQLines Data funcionar) e outra com Oracle Linux 6.5 64 bits, onde instalei o Informix Developer Edition e o Oracle para testes.

Preparando o ambiente Windows:

  Instalar o Oracle Database 11g Release 2 Client (11.2.0.1.0) for Microsoft Windows (32-bit) 

  Configurar o tnsnames.ora apontando para o banco Oracle:



 Instalar o Java:



 Instalar Driver JDBC do Informix:


Instalar o Informix Client SDK Developer Edition for Windows x86, 32-bit:



Testando o SQLines Data


Instalar o SQLines Data:



Verificando a conexão com o Oracle:



Executar o setnet32 para configurar a conexão com o Informix:




Verificando a conexão com o Informix:


Para testes, vou deixar o default (todas as tabelas):



Log de transferência das tabelas:



Validação após a transferência:


Log da transferência:


Testando o Ispirer SQL Ways


 Instalar o Ispirer:


Criar uma conexão ODBC para o Informix no Windows e selecioná-la na ferramenta:



Informar os dados de conexão com o Oracle:


Agora é possível escolher os objetos que serão migrados:


Definir o mapeamento dos objetos:


Selecionando algumas opções para o Export dos dados:


Selecionando algumas opções para o Import dos dados:


Sumário:


Execução da migração:


Resumo da migração:


Como foi dito anteriormente, essa ferramenta gera arquivos para serem importados pelo SQL*Loader: