TUNING FIRST_ROW

Tuning Oracle — admin @ 14:40

/* ———————————————————————————————
CURSO DE PERFORMANCE E TUNING SQL
PEDRO F. CARVALHO
WWW.PEDROFCARVALHO.COM.BR
CONTATO@PEDROFCARVALHO.COM.BR
ORACLE 9i, 10G e 11G
http://psoug.org/reference/hints.html
HINTS FIRST_ROWS
————————————————————————————————-*/

/* first_rows: Para forçar o uso de índice de modo geral. Faz com que o otimizador escolha um
caminho que apanha a 1º linha ou N linhas mais rapidamente. Você tenta receber num n de linhas o mais rápido possível
Em suma, o método de otimização first_rows_n vai melhorar os planos de execução de SQL para sistemas
OLTP que só precisam entregar a primeira parte de um conjunto maior de solução.
Obs : O otimizador ignora este hint em instruções DELETE, UPDATE e instruções
SELECT que incluem operações em bloco, tais como ordenações e agrupamentos

Este índice direciona uma consulta para ser otimizada com base na recuperação mais rápida da primeira linha.
Este tipo de índice é muito útil quando o desenvolvedor faz uma interface para o usuário que apanha um único
registro no banco de dados. E seria uma péssima opção para sistemas de relatórios, onde um número muito grande
de registros é selecionado.
Este índice é ignorado quando utilizamos as instruções UPDATE e DELETE, pois todas as linhas recuperadas serão
atualizadas ou excluídas. Também será ignorado quando utilizamos qualquer função de agrupamento
(GROUP BY, DISTINCT, INTERSECT, MINUS, UNION), pois todas as linhas para o agrupamento precisam ser recuperadas.

*/

— show parameter OPTIMIZER_MODE v$parameter

select * from v$parameter order by name
drop table INSERIR purge;

— CRIANDO UMA TABELA SIMPLES
CREATE TABLE INSERIR (NUMERO INTEGER,
NOME VARCHAR(50) ,
NASC DATE ,
SEXO VARCHAR(1) ,
SALARIO NUMBER(8,2) ,
POSICAO INTEGER );

— INSERINDO DADOS
DECLARE
I INTEGER;
BEGIN
I := 0;
WHILE I <= 100000 LOOP
INSERT INTO INSERIR VALUES (i, ‘TESTANDO HINT FIRST_ROWS’, ’25/05/2012′, ‘F’, 1500, i);
I := I + 1;
END LOOP;
COMMIT;
END;

— INSERINDO MAIS REGISTROS DIFERENTES
DECLARE
I INTEGER;
BEGIN
I := 0;
WHILE I <= 70000 LOOP
INSERT INTO INSERIR VALUES (i, ‘TESTANDO HINT FIRST_ROWS 2′, ’26/05/2012’, ‘M’, 2000, i);
I := I + 1;
END LOOP;
COMMIT;
END;
— PRIMEIRA ANALISE DO PLANO DE EXECUÇÃO
EXPLAIN PLAN FOR
SELECT * FROM INSERIR WHERE NUMERO between 300 and 310
and salario > 1500 ;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

/*—————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————–
| 0 | SELECT STATEMENT | | 23 | 1771 | 378 (1)| 00:00:05 |
|* 1 | TABLE ACCESS FULL| INSERIR | 23 | 1771 | 378 (1)| 00:00:05 |
—————————————————————————– */
— CRIANDO INDICE PARA O CAMPO DE CONSULTA
DROP INDEX IDX_INSERIR_NUMERO;
CREATE INDEX IDX_INSERIR_NUMERO ON INSERIR(NUMERO);

— VERIFICANDO O PLANO DE EXECUÇÃO APÓS A CRIAÇÃO DO INDICE
EXPLAIN PLAN FOR
SELECT * FROM INSERIR WHERE NUMERO between 300 and 350
and salario > 1500;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

/*————————————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
————————————————————————————————–
| 0 | SELECT STATEMENT | | 23 | 1771 | 374 (0)| 00:00:05 |
|* 1 | TABLE ACCESS BY INDEX ROWID| INSERIR | 23 | 1771 | 374 (0)| 00:00:05 |
|* 2 | INDEX RANGE SCAN | IDX_INSERIR_NUMERO | 845 | | 3 (0)| 00:00:01 |
————————————————————————————————– */

— verificando a quantidade de linhas que vai trazer
SELECT count(rowid) FROM INSERIR WHERE NUMERO between 300 and 310 and salario > 1500 ;

— aplicando o first_rows
EXPLAIN PLAN FOR
SELECT /*+ FIRST_ROWS(11)) */ * FROM INSERIR WHERE NUMERO between 300 and 350
and salario > 1500;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
/*————————————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
————————————————————————————————–
| 0 | SELECT STATEMENT | | 23 | 1771 | 325 (0)| 00:00:04 |
|* 1 | TABLE ACCESS BY INDEX ROWID| INSERIR | 23 | 1771 | 325 (0)| 00:00:04 |
|* 2 | INDEX RANGE SCAN | IDX_INSERIR_NUMERO | | | 2 (0)| 00:00:01 |
————————————————————————————————– */

TUNING APPEND

Tuning Oracle — admin @ 14:39

/* ———————————————————————————————
CURSO DE PERFORMANCE E TUNING SQL
PEDRO F. CARVALHO
WWW.PEDROFCARVALHO.COM.BR
CONTATO@PEDROFCARVALHO.COM.BR
ORACLE 9i, 10G e 11G
INSERT COM HINT APPEND – DIRECT PATCH
————————————————————————————————-*/

/*Conhecido como INSERT COM DIRECT PATH, é mais rápido que o insert normal pois ele cria novos
blocos de memória para registrar essas inserções assim não procurando espaços vazios em
blocos já utilizáveis. Evite atualizar esta tabela quando estiver ocorrendo muitas
atualizações na tabela.*/

— CRIANDO UMA TABELA SIMPLES
DROP TABLE INSERIR;
CREATE TABLE INSERIR (NUMERO INTEGER, NOME VARCHAR(50), NASC DATE);

— INSERINDO DADOS SEM O HINT
DECLARE
I INTEGER;
BEGIN
I := 0;
WHILE I <= 500000 LOOP
INSERT INTO INSERIR VALUES (1, ‘INSERT COM APPEND HINT’, ’25/05/2012′);
I := I + 1;
END LOOP;
COMMIT;
END; — 23,93

SELECT * FROM INSERIR;

— INSERINDO DADOS COM O HINT
DECLARE
I INTEGER;
BEGIN
I := 0;
WHILE I <= 500000 LOOP
INSERT /*+append*/ INTO INSERIR VALUES (1, ‘INSERT COM APPEND HINT’,’25/05/2012′);
I := I + 1;
END LOOP;
COMMIT;
END; — 20,10

SELECT * FROM INSERIR;
TRUNCATE TABLE INSERIR;

TUNING ORACLE BIND VARIABLES

Tuning Oracle — admin @ 14:31

/* ———————————————————————————————
CURSO DE PERFORMANCE E TUNING SQL
PEDRO F. CARVALHO
WWW.PEDROFCARVALHO.COM.BR
CONTATO@PEDROFCARVALHO.COM.BR
ORACLE 9i, 10G e 11G
USANDO VARIÁVEIS BIND
————————————————————————————————-*/

/* Use variáveis BIND*/

— criar uma tabela
drop table t purge;
create table t(x number, y number);
insert into t select rownum, rownum from dual connect by level <= 1000;
commit;

Ok, com a tabela criada vamos primeiro tomar a medida da quantidade de parses executadas
até o momento para termos como base. Isto é feito com a query abaixo:

select sn.name, vm.value
from v$mystat vm,
v$statname sn
where vm.statistic# = sn.statistic#
and sn.name like ‘%parse%’;
Esta query resume as principais estatísticas da sessão com relação ao parse.
Estamos mais interessados, no entanto, no parse count (total) e no parse count (hard).
Tenha em mente o seguinte: o parse count (total) é a soma de todos os parses executados,
sejam eles hard ou soft. A diferença entre um parse hard e um soft é que no hard parse
o banco precisa validar a query e estabelecer o plano de execução, um processo bastante
demorado e consumidor de recursos. Já no soft parse, o banco apenas verifica se a query
já existe na shared pool e reaproveita o plano existente, economizando aí um tempo
bastante significativo. Pelas estatisticas acima, para saber a quantidade de soft
parses basta subtrair a quantidade de hard parses do total.
Vamos então executar o bloco anônimo com o código que utiliza concatenação de valores para
gerar as diversas querys.
declare
v_num number;
t0 number := dbms_utility.get_time;

begin
for r1 in (select rownum from dual connect by level <= 100)
loop
for r2 in (select rownum from dual connect by level <= 1000)
loop
execute immediate ‘select y from t where x = ‘ || r2.rownum into v_num;
end loop;
end loop;
dbms_output.put_line(‘hsecs=’ || (dbms_utility.get_time – t0));
end;

— executar novamente
select sn.name, vm.value
from v$mystat vm,
v$statname sn
where vm.statistic# = sn.statistic#
and sn.name like ‘%parse%’;

— com bindo variables
declare
v_num number;
t0 number := dbms_utility.get_time;

begin
for r1 in (select rownum from dual connect by level <= 100)
loop
for r2 in (select rownum from dual connect by level <= 1000)
loop
execute immediate ‘select y from t where x = :1’ into v_num using r2.rownum;
end loop;
end loop;
dbms_output.put_line(‘hsecs=’ || (dbms_utility.get_time – t0));
end;

select sn.name, vm.value
from v$mystat vm,
v$statname sn
where vm.statistic# = sn.statistic#
and sn.name like ‘%parse%’;

NAME VALUE
—————————————————————- —–
parse time cpu 0
parse time elapsed 0
parse count (total) 30
parse count (hard) 2
parse count (failures) 0

bloco anônimo concluído
NAME VALUE
—————————————————————- —–
parse time cpu 226
parse time elapsed 247
parse count (total) 102034
parse count (hard) 2002
parse count (failures) 0

bloco anônimo concluído
NAME VALUE
—————————————————————- —–
parse time cpu 226
parse time elapsed 247
parse count (total) 102041
parse count (hard) 2005
parse count (failures) 0

TUNING PACOTE DBMS_REWRITE

Tuning Oracle — admin @ 14:19

/* ———————————————————————————————
CURSO DE PERFORMANCE E TUNING SQL
PEDRO F. CARVALHO
WWW.PEDROFCARVALHO.COM.BR
CONTATO@PEDROFCARVALHO.COM.BR
ORACLE 9i, 10G e 11G
DEMONSTRAÇÃO DO PACOTE DBMS_ADVANCED_REWRITE VIEW
————————————————————————————————-*/
/*
Demonstrar a utlização deste pacote com uma view em uma consulta
Este permite a alteração de uma consulta sem alteração do código fonte da aplicação.

O pacote DBMS_ADVANCED_REWRITE permite interceptar instruções SQL específicas e
substituí-las com instruções SQL alternativa. Este recurso pode ser muito útil
quando precisamos modificar uma instrução SQL visando melhoria de performace e não
dispomos do código fonte da aplicação. Infelizmente este recurso tem algumas
limitações e em alguns casos não podemos utilizá-lo:

Recurso disponível a partir da versão Oracle 10g;
Não funciona com instrução DML, somente com instrução SELECT;
Não funciona com “Bind Variables” (Metalink DOC ID: 392214.1);
*/

drop table rewrite_teste_tab purge
drop view rewrite_teste_tab_v
CREATE USER rec IDENTIFIED BY rec
DEFAULT TABLESPACE “USERS”
TEMPORARY TABLESPACE “TEMP”;

— DESIGNANDO ACESSO A ELE
grant connect, resource to rec;
grant execute on dbms_advanced_rewrite to rec

CREATE TABLE rec.rewrite_teste_tab (
id NUMBER PRIMARY KEY,
description VARCHAR2(50));

INSERT INTO rec.rewrite_teste_tab (id, description) VALUES (1, ‘GLASGOW’);
INSERT INTO rec.rewrite_teste_tab (id, description) VALUES (2, ‘BIRMINGHAM’);
INSERT INTO rec.rewrite_teste_tab (id, description) VALUES (3, ‘LONDON’);
COMMIT;
— verificar os dados da tabela
SELECT * FROM rec.rewrite_teste_tab;

— criar uma view com o objetivo de mudar o campo descripstion para aparecer como maiusculo
CREATE OR REPLACE VIEW rec.rewrite_teste_tab_v AS
SELECT id,
INITCAP(description) AS description
FROM rec.rewrite_teste_tab
ORDER BY description;

— usando o pacote advanced_rewrite
BEGIN
SYS.DBMS_ADVANCED_REWRITE.declare_rewrite_equivalence (
name => ‘test_rewrite’,
source_stmt => ‘SELECT * FROM rec.rewrite_teste_tab’,
destination_stmt => ‘SELECT * FROM rec.rewrite_teste_tab_v’,
validate => FALSE,
rewrite_mode => ‘TEXT_MATCH’);
END;
— um select na tabela
SELECT * FROM rec.rewrite_teste_tab

— ALTERAR A NIVEL DE SESSÃO PARA REALIZAR A TROCA
select * from v$parameter order by name
ALTER system SET QUERY_REWRITE_INTEGRITY = TRUSTED;
ALTER SESSION SET QUERY_REWRITE_INTEGRITY = TRUSTED;

— select para a troca, ele vai usar a view agora.
SELECT * FROM rec.rewrite_teste_tab

— VERIFICANDO TODAS AS EQUIVALENCIAS
SELECT * FROM user_rewrite_equivalences;

— apagar a equevalencia
BEGIN
DBMS_ADVANCED_REWRITE.DROP_REWRITE_EQUIVALENCE (name => ‘test_rewrite’);
END;

 

Utilização de Advisors

Tuning Oracle — admin @ 3:41

Conclusão

Oracle fez um grande investimento no desenvolvimento de OEM com o objetivo de criar uma interface de one-stop para a miríade de tarefas de administração da Oracle. As ferramentas de ajuste estão cheias ao longo das dezenas de telas complexas e confusas.

Por outro lado, ferramentas de terceiros, tais como Ion e DBFlash fornecer uma ferramenta específica para a tarefa que fornece o DBA experiente com um bisturi para uso em encontrar e corrigir baixo desempenho SQL cirurgicamente.

§ abordagem inteligente: Utilizando o Oracle esperar interface e estatísticas da Oracle específicos e amarrando essa informação de volta para as suas declarações fonte de SQL, ferramentas como DBFlash permitir a correção dos problemas específicos em uma carteira de Oracle SQL banco de dados, eliminando a afinação do aparentemente ruim SQL que, de fato, não é um problema de todos. Em contraste, o assessor de Acesso SQL da Oracle faz recomendações globais apenas em índices e visualizações materializadas X “visões materializadas”, enquanto o assessor SQL Sintonia faz recomendações específicas; no entanto, estas recomendações podem ser feitas com inteligência limitada. O SQL Access Advisor é uma ferramenta limitada, e só pode recomendar soluções simples, como novos índices e visualizações materializadas, ignorando as dezenas de outras opções de ajuste de SQL.

§ Menos sobrecarga: Enquanto AWR, através da utilização do processo de fundo MMON, é mais eficiente na coleta de estatísticas do que o uso da interface tarefa Oracle era para STATSPACK, ele ainda tem mais impacto no desempenho do que algumas ferramentas de terceiros.

§ Menos caro: a Oracle ASH é um componente do Oracle Enterprise Manager X “Oracle Enterprise Manager” Diagnostic Pack e Oracle Sintonia Pack. Estas são características de custo extra, e eles devem ser licenciados separadamente. Os custos destes pacotes de ajuste podem ser proibitivamente caro para algumas lojas.

§ bem focada: As telas de OEM não estão focados em gestão de desempenho, mas sim todo o banco de dados ou bancos de dados que estão sendo monitorados e seu estado geral. O usuário OEM pode apresentado com uma enorme gama de opções.

§ identificação rápida problema: Em comparação com OEM, problema SQL pode ser rapidamente encontrada por ferramentas como Ion e DBFlash dentro de poucos cliques do mouse. A interface de OEM e SQL Analyzer o DBA pode enfrentar uma provação de postos de trabalho de análise e correção programados. A interface OEM pratica uma quantidade extrema de exploração de mão, enquanto garante ao DBA inexperiente, que pode ser irritante para o DBA mais experiente. A interface DBFlash assume um DBA experiente está ao leme.

§ sintonia Soluções rápidas: Savvy DBAs sabem que os testes de carga de trabalho de longo prazo não ajudar a ajustar mais SQL. Oracle alega que muitas instruções SQL Oracle vai mudar os planos de execução como as mudanças de carga de trabalho. Embora isto seja verdade para um pequeno número de lojas, a grande maioria das lojas da Oracle vai descobrir que há um, e apenas um, o plano de execução ideal para qualquer instrução SQL.

Este capítulo tem incidido sobre os componentes Oracle10g empresa de ajuste Manager e sobre como OEM exibe dados AWR e cinzas em uma forma visual.

Enquanto as telas de desempenho OEM são built-in para o console OEM, muitos profissionais da Oracle não estão cientes de que o uso dessas telas pode exigir licenças adicionais Oracle. Ferramentas de terceiros que ignoram os pontos de vista AWR e cinzas, por vezes, pode fornecer uma solução mais rentável.

Finalmente, é de salientar que as ferramentas eschew GUI muitos de DBA sênior e uso personalizado scripts para expor problemas de desempenho da Oracle.

O próximo capítulo irá explorar técnicas para ajustar Sistemas Oracle Cluster e investigar Real Application Clusters (RAC) e ajuste para sistemas de rede Oracle10g.

Indices baseado em funções

Tuning Oracle — admin @ 2:33

Abaixo um exemplo de indice baseado em função

Demonstro a criação de uma tabela T e sendo carregada de dados vindos da view dba_objects. Após isso é realizado um select para trazer todos os dados onde o object_type seja igual a TABLE usando funções dos dois lados da comparação. Vejam que o plano de execução 1 retornou um time de 4 segundos e o custo de processamento 321 para trazer esses dados. Após isso criamos o índice idx_t_type não baseado em função e executamos novamente a consulta com o plano de execução e vemos que nada adiantou, a consulta ainda  fez um table full scan na tabela T.  Para vermos os índices baseado em função crio após isso o índice idx_t_type_fun esse baseado em função e vejam que a consulta com o plano de execução em seu time caiu para 1 e seu custo caiu para 22.

 

create table t as select * from dba_objects;
explain plan for
select * from t where upper(object_type) = upper(‘table’);
select * from table (dbms_xplan.display);
————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
————————————————————————–
| 0 | SELECT STATEMENT | | 8654 | 1495K| 321 (1)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T | 8654 | 1495K| 321 (1)| 00:00:04 |
————————————————————————–
create index idx_t_type on t(object_type);
————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
————————————————————————–
| 0 | SELECT STATEMENT | | 8654 | 1495K| 321 (1)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T | 8654 | 1495K| 321 (1)| 00:00:04 |
————————————————————————–
create index idx_t_type_fun on t(upper(object_type));
———————————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
———————————————————————————————-
| 0 | SELECT STATEMENT | | 8654 | 1495K| 22 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T | 8654 | 1495K| 22 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX_T_TYPE_FUN | 368 | | 5 (0)| 00:00:01 |
———————————————————————————————-

TIPOS DE INDICES ORACLE

Administração,Tuning Oracle — admin @ 4:40

Padrão B-tree

índice de árvore equilibrada; bom para de alta cardinalidade (alto grau de distintas
valores) colunas. Use um índice normal de árvore-B, a menos que você tenha um motivo concreto
para usar um tipo de índice diferente ou recurso.

Índice tabela organizada IOT

Eficiente quando a maioria dos valores de coluna são incluídos na chave primária. Vocês
aceder ao índice, como se fosse uma tabela. Os dados são armazenados numa B-tree como
estrutura.

Unique

A única forma de índice B-árvore; usado para impor exclusividade em valores de coluna. Frequentemente
usado com chave primária e restrições de chaves únicas, mas pode ser criado
independentemente de constrangimentos.

Reverse Key

A forma de índice B-árvore; útil para equilibrar o I / O em um índice que tem muitos
inserções seqüenciais.

Key-compressed

Bom para índices concatenadas onde a coluna líder é muitas vezes repetidas;
comprime entradas de bloco de folhas. Esse recurso se aplica a uma árvore B ou um índice IOT.

Descending

Descendo uma forma de índice B-árvore; usado com índices correspondentes onde os valores da coluna são classificadas em ordem decrescente (a ordem padrão é ascendente). Você não pode especificar decrescente para um índice de chave inversa e Oracle ignora descendente se o tipo de índice é bitmap.

Bitmap

Excelente Bitmap em ambientes de data warehouse com colunas de baixa cardinalidade e
Instruções SQL usando muitos operadores E ou OU na cláusula WHERE. Bitmap
índices não são adequados para o processamento de transações on-line (OLTP) bases de dados
onde as linhas são atualizados com freqüência. Você não pode criar um índice de bitmap único.

Bitmap join

Bitmap juntar-se útil em ambientes de data warehouse para consultas que utilizam esquema em estrela
estruturas que ligam tabelas de fatos e dimensão.

Function based

Bom para colunas que têm funções SQL aplicadas a eles baseado em função. Isto pode ser usado
quer com uma árvore B ou índice de bitmap.


Index Virtual Column

Um índice definido em uma coluna virtual (de uma tabela); útil para colunas que têm
Funções SQL aplicadas a eles; alternativa viável ao uso de uma função de base-
índice. Virtual Permite criar um índice com nenhum segmento físico ou extensões, através do
NOSEGMENT cláusula de CREATE INDEX; útil no ajuste de SQL sem consumir
os recursos necessários para construir o índice físico. Qualquer tipo de índice pode ser criado
como virtual.

Invisible

O índice não é visível para o otimizador de consulta. No entanto, a estrutura do
índice é mantida como dados da tabela são modificados. Útil para testar um índice
antes de torná-lo visível para o aplicativo. Qualquer tipo de índice pode ser criado como
invisível.

Global partitioned

Particionado global Índice global em todas as partições de uma tabela particionada ou mesa regular. este
pode ser um tipo de índice B-tree e não pode ser um tipo de índice bitmap.

Local partitioned

Local índice particionado local com base em partições individuais em uma tabela particionada. Isto pode ser
ou uma árvore B ou tipo de índice bitmap.

Domain

Domínio específico para uma aplicação ou cartucho.

B-tree cluster

Aglomerado de árvore B Usado com tabelas em cluster.

Cluster de hash

usados ​​com clusters de hash.

Caminhos para Sql Tuning

Tuning Oracle — admin @ 23:34

Em meus treinamentos de Sql Tuning (Video aulas) abranjo toda esta arquitetura

Um plano estratégico para o ajuste Oracle SQL

Muitas pessoas perguntam onde devem começar ao ajustar Oracle SQL. Ajustando Oracle SQL é como a pesca. Você deve primeiro peixe no cache de biblioteca Oracle para extrair instruções SQL e classificar as declarações do seu volume de actividade.

Passo 1: Identificar de alto impacto SQL

As instruções SQL serão classificados de acordo o número de execuções e será sintonizado nesta ordem. A coluna execuções da visão v $ sqlarea e as estatísticas $ sql_summary ou a tabela dba_hist_sql_summary pode ser usado para localizar o SQL mais frequentemente utilizado. Note que podemos exibir instruções SQL por:

Rows processed: consultas que processam um grande número de linhas terão alta I / O e também pode ter impacto sobre o espaço de tabela TEMP.

Buffer gets:: recebe alta tampão pode indicar uma consulta intensiva de recursos.

Disk reads:: Alta disco lê indicam uma consulta que está causando excessiva I / O.

Memória KB: A alocação de memória de uma instrução SQL é útil para identificar as declarações que estão fazendo na memória tabela junta.

CPU secs:: Este identifica as instruções SQL que usam a maioria dos recursos do processador.

Sorts:: tipo pode ser um grande abrandamento, especialmente se eles estão sendo feito em um disco no espaço de tabela TEMP.

Executions: As instruções SQL mais freqüentemente executados deve ser ajustado em primeiro lugar, uma vez que terão o maior impacto sobre o desempenho global.

 

Passo 2: Determinar o plano de execução para SQL

Como cada instrução SQL é identificado, ele será “explicou” para determinar o seu plano de execução existente. Há uma série de ferramentas de terceiros no mercado que mostram o plano de execução para instruções SQL. A forma mais comum de determinar o plano de execução para uma instrução SQL é usar explicar utilitário plano da Oracle. Usando explicar plano, o DBA Oracle pode pedir Oracle para analisar a instrução e exibir o caminho de classe execução sem realmente executar a instrução SQL.

Para ver a saída de um plano de explicar, você deve primeiro criar uma “mesa plano.” A Oracle fornece um script em $ ORACLE_HOME / rdbms / admin chamado utlxplan.sql. Executar utlxplan.sql e criar um sinônimo público para o plan_table

 

Passo 3: Sintonize a instrução SQL

Para essas instruções SQL que possuem um plano de execução sub-óptima, o SQL será sintonizado por um dos seguintes métodos:
Adicionando ‘dicas’ de SQL para modificar o plano de execução

Re-escrever SQL com tabelas temporárias globais

Reescrevendo o SQL em PL / SQL. Para certas consultas isto pode resultar em mais do que uma melhoria de desempenho de 20x. O SQL seria substituída com uma chamada para um pacote de PL / SQL que continha um procedimento armazenado para realizar a consulta.

 

Usando referências para sintonizar o Oracle SQL

Entre as ferramentas mais comuns para declarações de ajuste de SQL são sugestões. Uma sugestão é uma directiva que é adicionada à instrução SQL para modificar o caminho de acesso para uma consulta SQL.
Solução de problemas dica! Para testar, você pode testar rapidamente o efeito de outro valor de parâmetro otimizador no nível de consulta sem usar um comando ‘alter sessão’, usando a nova dica opt_param SQL:

select/ * + opt_param (‘optimizer_mode’, ‘first_rows_10’) * / col1, col2. . .

select / * + opt_param (‘optimizer_index_cost_adj’, 20) * / col1, col2. .

A Oracle publica muitas dezenas de dicas de SQL e dicas de se tornar cada vez mais complicada através das várias versões do Oracle e em em Oracle.

Nota: As dicas são utilizados apenas para de-escuta e você deve ajustar suas estatísticas do otimizador para fazer a CBO replicar o SQL sugeriu. Vejamos as dicas mais comuns para melhorar a afinação:

Dicas de Modo: first_rows_10, first_rows_100
A Oracle líderes e ordenados dicas Veja também como mesa sintonia ordem de associação com histogramas

Amostragem dinâmica: dynamic_sampling

SQL Oracle dicas de afinação indocumentados – única do Guru

A dica de cardinalidade

Auto-fim da tabela junta – Se você achar que a Oracle está se juntando as tabelas juntos em uma ordem de sub-ótima, você pode usar a dica condenada a forçar as tabelas a serem unidas na ordem em que aparecem na cláusula FROM. Vejo
Tente uma dica first_rows_n. A Oracle tem dois modos otimizador baseado em custos, first_rows_n e ALL_ROWS. O modo first_rows irá executar para começar a retornar linhas, logo que possível, ao passo que o modo all_rows é projetado para otimizar os recursos em toda a consulta antes de retornar linhas.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
(c) 2017 | powered by WordPress with Barecity