Como foi o ENPO …
Um post rápido , como prometido, para registrar : Sábado houve o ENPO, e mais uma vez o evento foi um sucesso retumbante, casa cheia mesmo, fiz um monte de contatos, valeu muito a pena, como sempre… Até um velho amigo, que trabalhou comigo há uns 10 anos atrás, eu encontrei lá, realmente o ENPO tá virando o point de encontro dos profissionais Oracle, mesmo. De minha parte, a minha palestra sobre o sqlplus foi bem aceita pelo feedback imediato na hora, o pessoal se interessou pelo assunto (que claro, nem de longe é um tema complexo de “arquitetura” ou performance), mas que é de interesse, sim. Achei curioso o fato de que as features mais antigas (como BTITLE/TTILE, SETs, opções antigas de tunning como trace/tkprof, etc), que eu achei que iam suscitar mais dúvidas/interesse, não foram mencionadas, ao invés foi a geração de saída HTML (uma feature relativamente moderna) que gerou mais comoção…
De modo geral foi isso, e quem não foi, perdeu, agora só no ano que vem.
[]s
Chiappa
Link Permanente Comentários desativados
É amanhã! ENPO-BR…
Pessoal, amanhã novamente é dia de ENPO-BR, o único Evento versando sobre tecnologia Oracle no território nacional organizado, conduzido e apresentado por Profissionais da área, com foco apenas e tão-somente em discussões e apresentações técnicas : como não podia deixar de ser, faço questão de participar e vou palestrar, depois vou postar aqui sobre como foi…
Nos vemos lá !
Abraços,
José Laurindo Chiappa
Link Permanente Comentários desativados
Bind Variable Peeking e Performance de SQLs
Pessoal, antes de continuar a série sobre Fragmentação falando sobre índices, vou postar este artigo sobre Bind variable Peeking, pois diversas pessoas andaram me perguntando sobre isso, andaram rolando threads sobre isso nos grupos de discussão, então desencavei o texto que tinha começado sobre o assunto e dei uma garibada, vamos lá…
Primeiro, para entendermos a questão vou (ultra-rapidamente, prometo!) repassar o mecanismo de execução de SQLs no bd Oracle : sempre que vc (ou a sua tools/linguagem) envia um texto com comandos SQL ao banco, a primeira coisa que o banco faz é checar a sintaxe desse texto, se ele for válido (e se os objetos citados estão TODOS presentes, há permissões para eles, SE o ambiente não foi alterado, etc) o texto é transformado num “código” (hashing) e é feita uma busca por ele no cache de SQLs, se for encontrado ok, é esse SQL já em RAM que é executado com o mesmo plano de acesso anterior (que é armazenado junto com o SQL “codificado”), E caso não for encontrado um match exato para o texto do SQL, aí sim acontece o hard parsing, que envolve passos EXTREMAMENTE custosos, tais como a checagem dos planos/opções possíveis, a otimização (que envolve a montagem de muitos planos de acesso possíveis para o SQL e a comparação entre eles pra testar qual é o melhor), etc, resultando (em tese 
no melhor plano de acesso possível, que vai para o cache junto com o SQL recém-codificado.
OK, isto posto, aí surge um Segundo ponto, E SE o SQL contiver variáveis, não for sempre um texto fixo, for algo como :
SELECT nnn FROM TABELA WHERE colunachave = :X;
aonde X é uma variável, fará diferença se X tiver um ou outro valor qquer ? Pois o CBO (otimizador por Custo de SQLs) é capaz de analisar a quantidade de ocorrências de um valor numa dada coluna, através duma lista de ocorrências chamada HISTOGRAMA, e com ela saber se um dado valor é raro ou não, qual fração do total da tabela um dado valor retorna, isso poderia ser usado para otimização do plano a gerar… Até a versão 8i não havia escolha, o CBO simplesmente ignorava os Histogramas em qquer caso de presença de variáveis no SQL, então à pedidos a Oracle refinou esse mecanismo, e introduziu no banco 9i o conceito de BIND VARIABLE PEEKING : na primeira vez que o SQL é analisado (com HARD PARSE) o valor da variável é levado em conta, e portanto os histogramas da coluna se houverem são usados – isso é fácil de fazer em tempo de hard parse porque, óbvio, o valor das variáveis ainda está presente em RAM, pois a sessão interessada que enviou o SQL se está fazendo hard parse logicamente acabou de enviar o SQL, ainda está conectada, e variáveis residem na PGA, a área “particular” de cada sessão, então o valor está disponível necessariamente.
Explicados os dois conceitos-chave acima, chegamos então (ufa!) ao ponto deste post : imagine que, por azar total, o primeiro usuário a rodar um dado SQL do sistema que permite informar valores para filtros informa um valor muito frequente – em havendo histogramas na coluna o CBO vai os analisar, vai descobrir que o valor informado se repete muito, corretamente vai optar por varrer a tabela num full table scan ou algo similar. O que acontece se após isso um outro usuário (ou o mesmo, que seja) executa o mesmo SQL somente informando valor diferente, um valor raro que seria de bom-tom usar índices, para pesquisa ? Como nós dissemos acima, o SQL ** está ** em cache, já contém o plano original, é esse plano original com scan na tabela que vai ser usado, é isso, este é o risco do Bind variable Peeking para performance , ele NÃO ocorre sempre e portanto pode ser reusado um plano anterior não-apropriado, risco esse que permaneceu no banco 10g : foi só no banco 11g que a Oracle quase eliminou o risco, disponibilizando para o cache de SQLs permanentemente uma “cópia” dos valores usados nos BINDs de cada SQL anteriormente executado e que está em cache, e alterando a rotina de SQL matching para que, quando buscar por um SQL no cache, compare o valor de bind usado na sessão atual que enviou o SQL com o valor original do hard parse, SE forem diferentes a sub-rotina de avaliação de histogramas é acionada e um novo plano pode ser montado se for considerado proveitoso, essa feature se chama “bind-aware cursor matching”.
Aí vem as perguntas pra bancos pré-11g :
Como identificar se está havendo Bind peeking para um dado SQL ?
Resposta : levantar EXATAMENTE o SQL suspeito, que está apresentando má-performance, INCLUSIVE com os valores de bind variables (isto pode ser feito via TRACE no banco 9i ou via V$ próprias no 10g), e checar se já há um SQL com texto rigorosamente similar no cache (para o banco 10g inclusive dispomos dos BINDs usados em tempo de hard parse, no 9i não), verificar nas V$ e views DBA se há histogramas, testar o SQL suspeito re-executando com outros valores…
Como podemos prevenir o reuso de plano gerado anteriormente por bind variable peeking ?
Resposta : não há uma recomendação única, mas uma vez que vc entendeu a questão, se houver chance do problema ocorrer no seu sistema pode-se :
a) para os normalmente poucos casos onde isso ocorre, não usar bind, enviar para o banco SQLs do tipo :
SELECT nnn FROM tabela WHERE colunachave = 10;
SELECT nnn FROM tabela WHERE colunachave = 20;
Desvantagem : como sabemos nós, se vc abusar do envio de SQLs literais, cad um ocupa nova posição no cache, o cache será esgotado rapidamente, cada SQL terá texto diferente e implicará portanto em hard parse…. Muuuito cuidado !! ===>>> Óbvio, repito : usar isso nos POUCOS e RAROS casos aonde vc sabe que pode haver peeking !! E PREFERENCIALMENTE em sistemas DW/Batch, onde há POUCOS SQLs (embora muito complexos) rodando, E as tabelas são lidas em grandes porcentagens (para sumarizar/analisar dados), o que aumenta em muito a chance de diferenciação/não uso de informação na otimização por bind peeking
b) desabilitar peeking, via ALTER SESSION SET “_optim_peek_user_binds”=FALSE; em SQLs que exijam BINDs, que sejam frequentes
Desvantagem : isto volta ao status pré-9i, ie, o otimizador DESPREZARÁ as chances de planos diferentes (eventualmente talvez mais eficientes) com uso dos histogramas, o otimizador sem bind peek vai sempre CHUTAR, vai ESTIMAR a quantidade de linhas prum dado valor numa coluna – é TESTAR MUITO BEM SE no seu sistema, com os SEUS dados, esse “Chute” do CBO é aceitável.
OBS : uma variação desta técnica é simplesmente NÃO coletar histogramas nos objetos em questão, pode ser aceitável em alguns casos
c) usar HINTs, indicando o plano desejado qquer que sejam os inputs de usuário
Desvantagem : na prática isso “engessa” o CBO, perdemos a razão de ser do CBO, que é se adaptar ás novas circunstâncias – com HINTs, ainda que uma dada tabela ficou “grande” ou “pequena”, permitindo outras abordagens mais eficientes, com HINTs o plano SEMPRE é o mesmo, se um full table scan (digamos) é usado hoje nesse cenário e vai bem porque a tabela é “pequena”, com HINTs se a tabela crescer o FTS *** ainda *** vai ser usado, chances há de se obter performance insatisfatória.
===>> HINTs só devem ser por isso usadas ESPARSAMENTE, apenas em SQLs aonde NÃO se prevê alterações de volume significativas ** E ** Realmente outras opções não resultaram
d) “Forçar” um hard parse, que é onde pode haver bind peek : implica usar SQL dinâmico parcial, acrescentando um caracter qquer, uma diferenciação inócua qualquer (comentário talvez) a cada execução do SQL
Desvantagem : a óbvia, em caso de abuso da técnica a performance geral pode cair, pois cfrme dito cada hard parse é mais custoso do que um reuso, com hard parses frequentes o consumo (principalmente de CPU) cresce muito rapidamente
OBS : uma variação desta técnica é forçarmos uma invalidação de ambiente do SQL (pois cfrme dito no início do texto qquer alteração de ambiente/objeto implica em não reuso de SQL) : essa invalidação pode ser uma recoleta de estatísticas, um DDL qualquer (até um pequeno ALTER nalgum atributo secundário de alguma das tabelas)…
É isso, espero ter esclarecido esse mecanismo Oracle, que não é complexo mas é uma das causas comuns de “instabilidade” de performance em SQLs.
Abraços,
Chiappa
Qual a melhor ferramenta client Oracle open source ?
Antes de detalhar que a melhor ferramenta open source, vocês precisam entender porque não direi nada sobre as ferramentas gratuitas.
Existem boas opções gratuitas por aí, como o TOAD , AquaFold e outros, mas existe o problema da licença.
Algumas empresas começam oferecendo um bom software como freeware, as pessoas vão usando e reclamando/sugerindo mudanças. A empresa corrige, e quando a ferramenta atinge uma certa maturidade, ela simplesmente altera a licença e a sua ferramenta gratuita passa a ser uma versão pirata. A VMWare fez isso, e muitas outras fazem até hoje.
Usando uma ferramenta Open Source, esse risco não existe, pois a licença permite até que você altere o código fonte para a sua necessidade. Mesmo no caso que alguma empresa deseje comprar o código fonte, ela na verdade entra em acordo com os responsáveis do projeto e faz uma doação para enfatizar o uso. Isso aconteceu quando a Oracle usou fontes do Apache em parte de seu servidor de aplicação, e quando a BEA (que agora é da Oracle) quando usou o Eclipse como base de sua IDE de desenvolvimento.
Bom, voltando ao tópico principal, a minha ferramenta client preferida é o SQL Squirrel, que existe desde 2001 e hoje já atingiu uma maturidade de ferramenta profissional !
Ele possui diversas vantagens, sugiro que visite o site e comprove.
O download está disponível em diversas plataformas, Windows, Linux e outras.
E tudo isso sendo open source!
Espero que instalem e gostem da ferramenta, e não deixem de conferir o link de opções open source da própria Oracle:
Outras opções interessantes são:
Bom proveito !
Link Permanente Comentários desativados
Fragmentação no banco de dados Oracle : mitos e meias-verdades
Uma das falácias mais comuns e permanentes, sendo algo arraigado ao imaginário de muitos técnicos na área de databases, é a FRAGMENTAÇÃO, assunto sobre o qual muito se diz e pouco se explica, e que acaba servindo de justificativa para os mais diversos problemas de performance, e gerando os mais diversos MITOS e FOLCLORE : vamos começar este artigo definindo EXATAMENTE o assunto – de acordo com os dicionários (http://www2.uol.com.br/michaelis/ ) FRAGMENTAR deriva-se do substantivo FRAGMENTO, que significa pedaço, fração, assim FRAGMENTAÇÃO é o ato de FRAGMENTAR, reduzir a fragmentos, partir em pedaços; fracionar. Em TI, quando nos referimos à armazenamento em disco, tal ocorrência é uma consequência natural do fato dos Sistema Operacionais, para maior eficiência, não controlam o espaço em disco bit-a-bit, mas sim em grânulos (ie, clusters, blocos, páginas, enfim unidades de armazenamento) de maior tamanho – conforme são gravados arquivos que não sejam do tamanho exato do grânulo em uso, algum arredondamento e algum ajuste fatalmente será necessário. O que ocorre porém é que podem haver alguns efeitos negativos (para arquivos lidos sequencialmente do início ao fim) do fato de termos diversos fragmentos do arquivo, a saber :
- se os diferentes espaços em disco solicitados pelos diferentes arquivos forem não-múltiplos entre si, podemos vir a ter um arquivo A composto de fragmentos de x bytes e um arquivo B composto de fragmentos de y bytes alocados, com x e y diferentes e não-múltiplos entre si, quando um dos fragmentos de x bytes for liberado (após a remoção do dado nele contido, por exemplo) , ele não poderá ser usado pelo arquivo B, por causa dos tamanhos diferentes
- a quantidade de fragmentos a ler no total para acessar um dado arquivo, se for grande, implica em estruturas de controle maiscomplexas, uma lista maior será alocada, o que pode interferir negativamente. Na prática do dia-a-dia, por questão de simplificação, quando nos referimos à qualquer destes efeitos negativos da fragmentação, é dito que o “arquivo está fragmentado”, ou que “tal disco apresenta um alto índice de fragmentação nos seus arquivos” – como dito acima, isso não é essencialmente correto, mas tal simplificação (ie, os resultados sendo referidos pela causa) hoje é praxe. Muito bem, e o que esta teoria tem a ver com o banco de dados Oracle ? Este é o ponto que será demonstrado neste artigo , quase NADA é a resposta : devido à estrutura interna do bd Oracle (como demonstraremos) os efeitos acima observados da fragmentação de disco OU são FACILMENTE evitados usando-se tablespaces LMT (Local Managed Tablespaces, gerenciadas por bitmap) nas quais o tamanho mínimo alocado é SEMPRE regular), sendo que as tablespaces LMT por terem maior eficiência também IMPEDEM a ocorrência de problemas por quantidade de espaços alocados (extents) muito altos, a não ser em situações absolutamente limítrofes , como centenas de milhares de extents para um segmento, o que é FACILMENTE evitado com um planejamento adequado, tal como demonstrado em http://www.oracle.com/technology/deploy/availability/pdf/defrag.pdf .Vamos às demonstrações e explicações (aqui falaremos apenas sobre TABELAS, índices possuem características próprias e serão abordados em artigos futuros) .
Demonstração 1 – indiferença de quantidade de extents : primeiro criaremos (sempre LMTs) uma tablespace com um único extent e depois uma com centenas de extents, veremos que NÃO há diferença significativa . Segue :
SYSTEM@10g:SQL> create TABLESPACE TS_1_EXTENT datafile 'C:\TS_1_EXTENT.DBF' SIZE
209780736 extent management local uniform SIZE 200M nologging;
Tablespace criado.
SYSTEM@10g:SQL>create TABLESPACE TS_N_EXTENTS datafile 'C:\TS_N_EXTENTS.DBF' SIZE
209780736 extent management local uniform SIZE 1m nologging;
Tablespace criado.
SYSTEM@10g:SQL>alter USER SCOTT quota unlimited ON TS_1_EXTENT;
Usuário alterado.
SYSTEM@10g:SQL>alter USER SCOTT quota unlimited ON TS_N_EXTENTS;
Usuário alterado.
SCOTT@10g:SQL>create TABLE T1 (c1 NUMBER, c2 VARCHAR2(4000))
TABLESPACE TS_1_EXTENT nologging PCTFREE 1 pctused 99;
Tabela criada.
SCOTT@10g:SQL>create TABLE T2 (c1 NUMBER, c2 VARCHAR2(4000))
TABLESPACE TS_N_EXTENTS nologging PCTFREE 1 pctused 99;
Tabela criada.
SCOTT@10g:SQL>insert /*+ APPEND */ INTO T1
(SELECT object_id, LPAD(object_name, 4000, '$')
FROM all_objects WHERE ROWNUM <= 25000
);
25000 linhas criadas.
SCOTT@10g:SQL>commit;
Commit concluído
SCOTT@10g:SQL>insert /*+ APPEND */ INTO T2
(SELECT object_id, LPAD(object_name, 4000, '$')
FROM all_objects WHERE ROWNUM <= 25000
);
25000 linhas criadas.
SCOTT@10g:SQL>commit;
Commit concluído
SCOTT@10g:SQL>set autotrace on
SCOTT@10g:SQL>set TIMING on
SCOTT@10g:SQL>select COUNT(*) FROM T1;
COUNT(*)
------------------
25000
Decorrido: 00:00:04.78
Plano de Execução
----------------------------------------------------------
Plan hash VALUE: 3724264953
-------------------------------------------------------------------
| Id | Operation | Name | ROWS | COST (%CPU)| TIME |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 5515 (1)| 00:00:43 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| T1 | 27493 | 5515 (1)| 00:00:43 |
-------------------------------------------------------------------
Note
-----
- dynamic sampling used FOR this statement
Estatística
----------------------------------------------------------
28 recursive calls
0 db block gets
25077 consistent gets
25000 physical reads
116 redo size
420 bytes sent via SQL*Net TO client
396 bytes received via SQL*Net FROM client
2 SQL*Net roundtrips TO/FROM client
0 sorts (memory)
0 sorts (disk)
1 ROWS processed
SCOTT@10g:SQL>select COUNT(*) FROM T2;
COUNT(*)
------------------
25000
Decorrido: 00:00:05.46
Plano de Execução
-------------------------------------------------------------------
Plan hash VALUE: 3321871023
-------------------------------------------------------------------
| Id | Operation | Name | ROWS | COST (%CPU)| TIME |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 5535 (1)| 00:00:43 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| T2 | 20396 | 5535 (1)| 00:00:43 |
-------------------------------------------------------------------
Note
-----
- dynamic sampling used FOR this statement
Estatística
----------------------------------------------------------
28 recursive calls
1 db block gets
25101 consistent gets
25029 physical reads
168 redo size
420 bytes sent via SQL*Net TO client
396 bytes received via SQL*Net FROM client
2 SQL*Net roundtrips TO/FROM client
0 sorts (memory)
0 sorts (disk)
1 ROWS processed
ou seja, a diferença de tempo entre a leitura dos dados numa tablespace com um só extent e os mesmos dados em centenas de extents foi de FRAÇÃO de segundo, basicamente RUÍDO …. mesmo o I/O é basicamente igual, foi de 25077 + 25000 = 50077 blocos para 1 extent e 25101+25029+1=50131 blocos para N extents, diferença irrisória, o próprio fato das tabelas internas do banco irem pra cache já explica diferença tçao pequena…
Demonstração 2 – indiferença da localização dos extents : o conceito básico que será demonstrado é que , ao contrário de uma aplicação mais simples e “burrinha” (como um Editor de textos, por exemplo), que TEM que ler os dados sequencialmente do início ao fim, no banco Oracle a informação é fisicamente guardada em arquivos (datafiles), mas tais arquivos *** NUNCA *** são lidos sequencialmente do início ao fim, E os datafiles SEMPRE são divididos internamente em EXTENTs (pedaços mínimos), sendo que os extents são compostos de BLOCOS de um tamanho físico, sempre regulares que por serem e tamanho conhecido podem ser acessados via FSEEK, o banco NÃO precisa nunca varrer os N extents anteriores para chegar até um dado extent X.
Exemplo : vamos criar numa tablespace um objeto cujs extents NÃO estão fisicamente contíguos entre si (haverá extents de outros objetos, TANTO vazios quanto “cheios” de dados entre eles), depois vamos recriar o objeto com extents contíguos, veremos que não haverá diferença palpável:
SYSTEM@10g:SQL>create tablespace TS_TESTE datafile 'C:\TS_TESTE_01.DBF' size 10M autoextend on
extent management local uniform size 1M nologging;
Tablespace criado.
SYSTEM@10g:SQL>select segment_name, extent_id, block_id, bytes from dba_extents where owner='SYSTEM' and tablespace_name='TS_TESTE' order by block_id;
SEGMENT_NAME EXTENT_ID BLOCK_ID BYTES
----------------------------------- --------- -------- -------
T1 0 9 1048576
T2 0 137 1048576
2 linhas selecionadas.
SYSTEM@10g:SQL>BEGIN
for x in 1..15 loop
insert /*+ APPEND */ into T1 select object_id, lpad(object_name, 4000, '$') from all_objects where rownum <= 512;
commit;
for y in 1..10 loop
insert /*+ APPEND */ into T2 select object_id, lpad(object_name, 4000, '$') from all_objects where rownum <= 512;
commit;
end loop;
end loop;
END;
/
Procedimento PL/SQL concluído com sucesso.
SYSTEM@10g:SQL>select segment_name, extent_id, block_id, bytes from dba_extents where owner='SYSTEM' and tablespace_name='TS_TESTE' order by block_id;
SEGMENT_NAME EXTENT_ID BLOCK_ID BYTES
----------------------------------- --------- -------- --------
T1 0 9 1048576
T2 0 137 1048576
T1 1 265 1048576
T1 2 393 1048576
T1 3 521 1048576
T1 4 649 1048576
T2 1 777 1048576
T2 2 905 1048576
T2 3 1033 1048576
T2 4 1161 1048576
T2 5 1289 1048576
T2 6 1417 1048576
T2 7 1545 1048576
T2 8 1673 1048576
T2 9 1801 1048576
T2 10 1929 1048576
T2 11 2057 1048576
T2 12 2185 1048576
T2 13 2313 1048576
T2 14 2441 1048576
T2 15 2569 1048576
T2 16 2697 1048576
T2 17 2825 1048576
T2 18 2953 1048576
T2 19 3081 1048576
T2 20 3209 1048576
T2 21 3337 1048576
T2 22 3465 1048576
T2 23 3593 1048576
.....
==> OU seja, entre cada extent de T1 há dezenas de extents do T2, vamos fazer uma consulta :
SYSTEM@10g:SQL>set timing on
SYSTEM@10g:SQL>set autotrace on
SYSTEM@10g:SQL>select count(*) from T1;
COUNT(*)
------------------
7680
1 linha selecionada.
Decorrido: 00:00:02.39
Plano de Execução
----------------------------------------------------------
Plan hash value: 3724264953
-------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 1716 (1)| 00:00:14 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| T1 | 6937 | 1716 (1)| 00:00:14 |
-------------------------------------------------------------------
Note
-----
- dynamic sampling used for this statement
Estatística
----------------------------------------------------------
5 recursive calls
1 db block gets
7787 consistent gets
7680 physical reads
2256 redo size
420 bytes sent via SQL*Net to client
396 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SYSTEM@10g:SQL>set autotrace off
==> agora vamos ter T1 com extents contíguos :
SYSTEM@10g:SQL>create table T1 (c1 number, c2 varchar2(4000)) nologging pctfree 1 pctused 99 tablespace TS_TESTE;
Tabela criada.
Decorrido: 00:00:00.03
SYSTEM@10g:SQL>BEGIN
2 for x in 1..15 loop
3 insert /*+ APPEND */ into T1 select object_id, lpad(object_name, 4000, '$') from all_objects where rownum <= 512;
4 commit;
5 end loop;
6 END;
7 /
Procedimento PL/SQL concluído com sucesso.
Decorrido: 00:00:02.32
SYSTEM@10g:SQL>set autotrace on
SYSTEM@10g:SQL>select count(*) from T1;
COUNT(*)
------------------
7680
1 linha selecionada.
Decorrido: 00:00:02.42
Plano de Execução
----------------------------------------------------------
Plan hash value: 3724264953
-------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 1716 (1)| 00:00:14 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| T1 | 6937 | 1716 (1)| 00:00:14 |
-------------------------------------------------------------------
Note
-----
- dynamic sampling used for this statement
Estatística
----------------------------------------------------------
28 recursive calls
1 db block gets
7789 consistent gets
7680 physical reads
2256 redo size
420 bytes sent via SQL*Net to client
396 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
PRATICAMENTE idêntico, comprova o estabelecido de que o banco Oracle lê os extents INDEPENDENTEMENTE, o fato de estarem numa ou noutra posição do disco, contíguos ou não, é basicamente indiferente, o que mostra como INVERDADE a falácia corrente de que é necesário “desfragmentar” um segmento para que os extents fiquem contíguos….
OBSERVAÇÃO IMPORTANTE : isso absolutamente NÃO QUER DIZER que nunca há queda de performance por eventual ineficiência de estruturas físicas no banco Oracle, correto ? O ponto que deve ser frisado é que elas existem mas ***** NÃO TEM A VER COM FRAGMENTAÇÃO DE DISCO ***** propriamente dita …. Vamos conhecer as principais e chamá-las pelos nomes mais apropriados, chamar tudo genericamente de “fragmentação” só serve para ESCONDER a realidade, só dificulta a administração, é IMPORTANTÍSSIMO as conhecer pelos nomes próprios e saber quando ocorrem e como as enfrentar, é o que veremos no meu próximo texto, até lá…
Link Permanente Comentários desativados
Oracle ?
Em breve o maior portal de artigos para Oracle em português…
Link Permanente Comentários desativados
