Re: [oracle_br] Re: CLUSTERING FACTOR

2017-12-19 Por tôpico Yana Disconzi ydisco...@hotmail.com [oracle_br] 
Sim, as coisas vão ficando  mais claras pra mim.
Obrigada pela indicação do livro Oracle SQL High-Performance, vou atrás hoje 
mesmo.


Obrigada pelos esclarecimentos, fizeram diferença pra minha visão do problema.

Abss,




De: oracle_br@yahoogrupos.com.br <oracle_br@yahoogrupos.com.br> em nome de 
jlchia...@yahoo.com.br [oracle_br] <oracle_br@yahoogrupos.com.br>
Enviado: terça-feira, 19 de dezembro de 2017 06:37
Para: oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] Re: CLUSTERING FACTOR



Sim : inclusive, clustering factor *** NÂO TEM NADA A VER *** com redução de 
I/O per se : ele é simplesmente um indicador, uma referência se os dados dentro 
do índice estão bastante 'espalhados' por múltiplos blocos ou não, e é usado 
como fator de DESEMPATE para o Otimizador escolher quando houver mais de um 
índice possível... E Imagino que vc ENTENDEU quando eu disse que o CF é uma 
medida de organização da tabela, se fisicamente a tabela está organizada mais 
coerentemente com a coluna X , não tem ao mesmo tempo como ela Também estar 
organizada fisicamente pela coluna Y ao mesmo tempoNÃO EXISTE isso de 
'melhorar o clustering factor para a query' , o CF é PARA A TABELA COMO UM 
TODO, okdoc 

 Então SIM, eu Recomendo que vc parte pras opções de Tuning de SQL : via de 
regra tuning de SQL é muuito mais simples e mito mais Efetivo, vc 
consegue resultados melhores de uma maneira mais simples... O passo inicial 
para tuning de SQL é obter Conhecimento sobre os índices E as tabelas 
envolvidas na query (o que inclui a razão / regra de negócio que te leva a 
sub-queries, por exemplo), TEM que saber os volumes estimados para cada acesso 
via cada índice E tem que conhecer os métodos de JOIn (ie, HASH JOIN, NESTED 
LOOPs, SORT_mERGE, etc) para poder avaliar o Plano de Execução que o Otimizador 
vai te dar e validar se ele está o mais otimizado possível ou não... Por 
exemplo, pegando o exemplo em 
www.oracle..com/technetwork/database/bi-datawarehousing/twp-explain-the-explain-plan-052011-393674.pdf
 o Otimizador escolher fazer um HASH JOIN, ie, ler na íntegra as tabelas 
envolvidas criando uma tabela temporária em memória ordenada e então filtrar os 
dados por essas tabelas temporárias - isso é RADICALMENTE DIFERENTE de NESTED 
LOOP, onde ele vai lendo os dados linha a linha e para cada linha lida o RDBMS 
procura nas outrs tabelas pra ver se tem um valor correspondente Qual o 
melhor/mais correto ? DEPENDE dessas infos que citei
  Na minha experiência pessoal, a fonte que melhor explicou esses diferentes 
métodos de JOIN foi o livro "Oracle SQL High-Performance Tuning", de Guy 
Harrison , Recomendo que vc o leia...

 O passo inicial do método para Tuning de SQL que recomendo portanto é : COM o 
conhecimento teórico da metodologia do Otimizador de SQL presente E conhecendo 
também volumes e distribuição de dados nas tabelas e índices envolvidas, 
obtenha o Plano de Execução extendido (ie, que inclui qtdades estimadas versus 
qtdades efetivamente obtidas) cfrme 
https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate
  Com isso aí vc vai analisar se o índice e o método de JOIN tão 
apropriados ou se vc acredita que outro seria mais efetivo, se as Estatísticas 
que guiam as Estimativas do RDBMS tão apropriadas, é por aí

[]s

  Chiappa

[oracle_br] Re: CLUSTERING FACTOR

2017-12-19 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Sim : inclusive, clustering factor *** NÂO TEM NADA A VER *** com redução de 
I/O per se : ele é simplesmente um indicador, uma referência se os dados dentro 
do índice estão bastante 'espalhados' por múltiplos blocos ou não, e é usado 
como fator de DESEMPATE para o Otimizador escolher quando houver mais de um 
índice possível... E Imagino que vc ENTENDEU quando eu disse que o CF é uma 
medida de organização da tabela, se fisicamente a tabela está organizada mais 
coerentemente com a coluna X , não tem ao mesmo tempo como ela Também estar 
organizada fisicamente pela coluna Y ao mesmo tempoNÃO EXISTE isso de 
'melhorar o clustering factor para a query' , o CF é PARA A TABELA COMO UM 
TODO, okdoc  

 Então SIM, eu Recomendo que vc parte pras opções de Tuning de SQL : via de 
regra tuning de SQL é muuito mais simples e mito mais Efetivo, vc 
consegue resultados melhores de uma maneira mais simples... O passo inicial 
para tuning de SQL é obter Conhecimento sobre os índices E as tabelas 
envolvidas na query (o que inclui a razão / regra de negócio que te leva a 
sub-queries, por exemplo), TEM que saber os volumes estimados para cada acesso 
via cada índice E tem que conhecer os métodos de JOIn (ie, HASH JOIN, NESTED 
LOOPs, SORT_mERGE, etc) para poder avaliar o Plano de Execução que o Otimizador 
vai te dar e validar se ele está o mais otimizado possível ou não... Por 
exemplo, pegando o exemplo em 
www.oracle.com/technetwork/database/bi-datawarehousing/twp-explain-the-explain-plan-052011-393674.pdf
 o Otimizador escolher fazer um HASH JOIN, ie, ler na íntegra as tabelas 
envolvidas criando uma tabela temporária em memória ordenada e então filtrar os 
dados por essas tabelas temporárias - isso é RADICALMENTE DIFERENTE de NESTED 
LOOP, onde ele vai lendo os dados linha a linha e para cada linha lida o RDBMS 
procura nas outrs tabelas pra ver se tem um valor correspondente Qual o 
melhor/mais correto ? DEPENDE dessas infos que citei 
  Na minha experiência pessoal, a fonte que melhor explicou esses diferentes 
métodos de JOIN foi o livro "Oracle SQL High-Performance Tuning", de Guy 
Harrison , Recomendo que vc o leia...

 O passo inicial do método para Tuning de SQL que recomendo portanto é : COM o 
conhecimento teórico da metodologia do Otimizador de SQL presente E conhecendo 
também volumes e distribuição de dados nas tabelas e índices envolvidas, 
obtenha o Plano de Execução extendido (ie, que inclui qtdades estimadas versus 
qtdades efetivamente obtidas) cfrme 
https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate
  Com isso aí vc vai analisar se o índice e o método de JOIN tão 
apropriados ou se vc acredita que outro seria mais efetivo, se as Estatísticas 
que guiam as Estimativas do RDBMS tão apropriadas, é por aí

[]s

  Chiappa

[oracle_br] Re: CLUSTERING FACTOR

2017-12-18 Por tôpico ydisco...@hotmail.com [oracle_br] 
Bom dia Pessoal,

Obrigada jlchiappa pelo retorno. Estou em processo de desenvolvimento nesta 
parte de tuning.
Desculpe se não fui clara o suficiente com as informações necessárias. 


1.Coloquei na mensagem anterior a tabela com essas informações.  

 SEGMENT_NAME
 SEGMENT_TYPE
 BLOCKS
 EXTENTS
 GB
 ROWS
 TB_ESTOQUE_ENTRADA2
 TABLE 
 5.438.208
 850
 41,49
 414.612.027
 
 Average rows per data block= 193

 

 
2. Sim, a tabela possui muitas colunas. Então, para diminuir o I/O desta query 
nesta tabela, seria melhor encontrar outras formas como o 
Particionamento,compressão,tabela em cluster do que melhorar o CF?
   

 

---Em oracle_br@yahoogrupos.com.br,  escreveu:

 Bom, primero pergunto, quanto é 400KK - seria 400 mil milhares, ie, 400 
milhões ?? E segundo sorry, mas NÚMERO DE LINHAS não é significativo pra gente 
isoladamente - esse X de linhas representa QUANTOS BYTES/megabytes/gigabytes 
efetivamente ?? E terceiro ponto, como está a Média de linhas por bloco físico 
nessa tabela ?

 Mas de qquer maneira : a primeira coisa que TENHO que observar é que o CLUSTER 
FACTOR é relacionado com a localização Física dos dados indexados na tabela : 
Obviamente, não tem como Fisicamente a mesma tabela ter os dados ordenados pela 
coluna X ** e ** pela coluna Y ao mesmo tempo, então fique CIENTE que se vc 
alterar/melhorar o cluster factor da tabela em relação a um índice A, muito 
certamente vc vai PIORAR em relação a um índice B... Lógico 
  Julgando por esse nome de IN_ESTENTRADA_LOTEAPRES2 , me parece que esse Não É 
o único índice dessa tabela, então VEJA LÁ se mexendo no CF de um ídnice vc Não 
Estraga o de outro índice, usado por OUTRAs Consultas Legal ??
  
 Isso posto, aí sim a sua resposta... Primeiro teste, cfrme 
http://www.oracle.com/technetwork/issue-archive/2012/12-sep/o52asktom-1735913.html
 e 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:9524251800346726054
 (e os links deste último) demonstram sim, para vc alterar o CF é fisicamente 
recriar a tabela Tenta em primeiro lugar ao invés de TRUNCAR a tabela e 
reinserir os dados (o que vai reaproveitar o mesmo segmento MAS adicionando 
novos extents) criar uma NOVA tabela (chame de TAB_ORGANIZED) com os dados 
vindos da tabela em análise ordenados num CREATE TABLE AS SELECT e depois 
criando um índice , como mostrado no primeiro link... Pra ser mais seguro 
ainda, faça isso numa tablespace LMT com gerenciamento automático... 
==> SE esse teste não resultar em alteração nenhuma do CF a gente começa a 
suspeitar de algum atributo físico que esteja 'forçando' os dados a se espalhar 
por N blocos : talvez um registro lógico extenso ?? Montes e montes de colunas 
na tabela em questão ?? OBVIAMENTE, se os dados não couberem com mita folga 
dentro do bloco, algum tipo de row chaining/row migration vai ser quase certo, 
aí o CF vai pras picas...

[]s

  Chiappa

Re: [oracle_br] Re: CLUSTERING FACTOR

2017-12-15 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Exatamente pessoal, estou de acordo com voces. O chamado com a SAP ja esta 
aberto, e so alteramos algo com a autorizacao da SAP.
Chiappa, realizei o que vc me pediu, mas nao obtive sucesso, o plano de 
execucao soh me mostra o E-rows.
Alterei o parametro a nivel de sessao.
Note-   - Warning: basic plan statistics not available. These are only 
collected when:       * hint 'gather_plan_statistics' is used for the statement 
or       * parameter 'statistics_level' is set to 'ALL', at session or system 
level

51 rows selected.
SQL> show parameter statistics_level
NAME                                 TYPE        
VALUE --- 
--statistics_level                     string      
ALL

 

Em Sexta-feira, 15 de Dezembro de 2017 14:58, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, primero pergunto, quanto é 400KK - seria 400 mil milhares, ie, 400 
milhões ?? E segundo sorry, mas NÚMERO DE LINHAS não é significativo pra gente 
isoladamente - esse X de linhas representa QUANTOS BYTES/megabytes/gigabytes 
efetivamente ?? E terceiro ponto, como está a Média de linhas por bloco físico 
nessa tabela ?

 Mas de qquer maneira : a primeira coisa que TENHO que observar é que o CLUSTER 
FACTOR é relacionado com a localização Física dos dados indexados na tabela : 
Obviamente, não tem como Fisicamente a mesma tabela ter os dados ordenados pela 
coluna X ** e ** pela coluna Y ao mesmo tempo, então fique CIENTE que se vc 
alterar/melhorar o cluster factor da tabela em relação a um índice A, muito 
certamente vc vai PIORAR em relação a um índice B... Lógico 
  Julgando por esse nome de IN_ESTENTRADA_LOTEAPRES2 , me parece que esse Não É 
o único índice dessa tabela, então VEJA LÁ se mexendo no CF de um ídnice vc Não 
Estraga o de outro índice, usado por OUTRAs Consultas Legal ??
  
 Isso posto, aí sim a sua resposta... Primeiro teste, cfrme 
http://www.oracle.com/technetwork/issue-archive/2012/12-sep/o52asktom-1735913.html
 e 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:9524251800346726054
 (e os links deste último) demonstram sim, para vc alterar o CF é fisicamente 
recriar a tabela Tenta em primeiro lugar ao invés de TRUNCAR a tabela e 
reinserir os dados (o que vai reaproveitar o mesmo segmento MAS adicionando 
novos extents) criar uma NOVA tabela (chame de TAB_ORGANIZED) com os dados 
vindos da tabela em análise ordenados num CREATE TABLE AS SELECT e depois 
criando um índice , como mostrado no primeiro link... Pra ser mais seguro 
ainda, faça isso numa tablespace LMT com gerenciamento automático... 
==> SE esse teste não resultar em alteração nenhuma do CF a gente começa a 
suspeitar de algum atributo físico que esteja 'forçando' os dados a se espalhar 
por N blocos : talvez um registro lógico extenso ?? Montes e montes de colunas 
na tabela em questão ?? OBVIAMENTE, se os dados não couberem com mita folga 
dentro do bloco, algum tipo de row chaining/row migration vai ser quase certo, 
aí o CF vai pras picas...

[]s

  Chiappa  #yiv2246574670 #yiv2246574670 -- #yiv2246574670ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2246574670 
#yiv2246574670ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2246574670 
#yiv2246574670ygrp-mkp #yiv2246574670hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2246574670 #yiv2246574670ygrp-mkp #yiv2246574670ads 
{margin-bottom:10px;}#yiv2246574670 #yiv2246574670ygrp-mkp .yiv2246574670ad 
{padding:0 0;}#yiv2246574670 #yiv2246574670ygrp-mkp .yiv2246574670ad p 
{margin:0;}#yiv2246574670 #yiv2246574670ygrp-mkp .yiv2246574670ad a 
{color:#ff;text-decoration:none;}#yiv2246574670 #yiv2246574670ygrp-sponsor 
#yiv2246574670ygrp-lc {font-family:Arial;}#yiv2246574670 
#yiv2246574670ygrp-sponsor #yiv2246574670ygrp-lc #yiv2246574670hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2246574670 
#yiv2246574670ygrp-sponsor #yiv2246574670ygrp-lc .yiv2246574670ad 
{margin-bottom:10px;padding:0 0;}#yiv2246574670 #yiv2246574670actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2246574670 
#yiv2246574670activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2246574670
 #yiv2246574670activity span {font-weight:700;}#yiv2246574670 
#yiv2246574670activity span:first-child 
{text-transform:uppercase;}#yiv2246574670 #yiv2246574670activity span a 
{color:#5085b6;text-decoration:none;}#yiv2246574670 #yiv2246574670activity span 
span {color:#ff7900;}#yiv2246574670 #yiv2246574670activity span 
.yiv2246574670underline {text-decoration:underline;}#yiv2246574670 
.yiv2246574670attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv2246574670 .yiv2246574670attach div a 
{text-decoration:none;}#yiv2246574670 .yiv2246574670attach img

[oracle_br] Re: CLUSTERING FACTOR

2017-12-15 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Bom, primero pergunto, quanto é 400KK - seria 400 mil milhares, ie, 400 milhões 
?? E segundo sorry, mas NÚMERO DE LINHAS não é significativo pra gente 
isoladamente - esse X de linhas representa QUANTOS BYTES/megabytes/gigabytes 
efetivamente ?? E terceiro ponto, como está a Média de linhas por bloco físico 
nessa tabela ?

 Mas de qquer maneira : a primeira coisa que TENHO que observar é que o CLUSTER 
FACTOR é relacionado com a localização Física dos dados indexados na tabela : 
Obviamente, não tem como Fisicamente a mesma tabela ter os dados ordenados pela 
coluna X ** e ** pela coluna Y ao mesmo tempo, então fique CIENTE que se vc 
alterar/melhorar o cluster factor da tabela em relação a um índice A, muito 
certamente vc vai PIORAR em relação a um índice B... Lógico 
  Julgando por esse nome de IN_ESTENTRADA_LOTEAPRES2 , me parece que esse Não É 
o único índice dessa tabela, então VEJA LÁ se mexendo no CF de um ídnice vc Não 
Estraga o de outro índice, usado por OUTRAs Consultas Legal ??
  
 Isso posto, aí sim a sua resposta... Primeiro teste, cfrme 
http://www.oracle.com/technetwork/issue-archive/2012/12-sep/o52asktom-1735913.html
 e 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:9524251800346726054
 (e os links deste último) demonstram sim, para vc alterar o CF é fisicamente 
recriar a tabela Tenta em primeiro lugar ao invés de TRUNCAR a tabela e 
reinserir os dados (o que vai reaproveitar o mesmo segmento MAS adicionando 
novos extents) criar uma NOVA tabela (chame de TAB_ORGANIZED) com os dados 
vindos da tabela em análise ordenados num CREATE TABLE AS SELECT e depois 
criando um índice , como mostrado no primeiro link... Pra ser mais seguro 
ainda, faça isso numa tablespace LMT com gerenciamento automático... 
==> SE esse teste não resultar em alteração nenhuma do CF a gente começa a 
suspeitar de algum atributo físico que esteja 'forçando' os dados a se espalhar 
por N blocos : talvez um registro lógico extenso ?? Montes e montes de colunas 
na tabela em questão ?? OBVIAMENTE, se os dados não couberem com mita folga 
dentro do bloco, algum tipo de row chaining/row migration vai ser quase certo, 
aí o CF vai pras picas...

[]s

  Chiappa