[oracle_br] Re: CLUSTERING FACTOR

[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: Consulta muito lenta!!

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

PEssoal, o problema foi resolvido.
A solução na qual tomei como base foi a extração do relatório SQLT pelo sqlid 
da consulta. E no SQLT existia a recomendação para criação de um sqlprofile, 
que o ganho seria de 99%, após a criação do sql_profile abaixo
execute dbms_sqltune.accept_sql_profile(task_name => 
'sqlt_s47584_mem',task_owner => 'SYS', replace => TRUE);

A query que rodava em 16 minutos, passou a rodar em 3 segundos.
Valeu pessoal, obrigado a todos. 

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

     Bom, pelo prompt de SQL> eu estou SUPONDO que vc optou por criar no 
sqlplus as bind variables todas necessárias e executar o SQL via sqlplus mesmo 
né ? Bom, DEVERIA FUNCIONAR certinho mas pra teste já que é assim mete o hint 
de gather_statistics mesmo no texto que vc entra entrando no sqlplus... Se 
ainda assim não mostrar o A-ROWs E o E-ROWs já repassa essa info pro Suporte 
SAP, é um sinal indicador que alguma coisa tá MUITO diferente nesse banco

[]s

  Chiappa
   #yiv4332546053 #yiv4332546053 -- #yiv4332546053ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4332546053 
#yiv4332546053ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4332546053 
#yiv4332546053ygrp-mkp #yiv4332546053hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4332546053 #yiv4332546053ygrp-mkp #yiv4332546053ads 
{margin-bottom:10px;}#yiv4332546053 #yiv4332546053ygrp-mkp .yiv4332546053ad 
{padding:0 0;}#yiv4332546053 #yiv4332546053ygrp-mkp .yiv4332546053ad p 
{margin:0;}#yiv4332546053 #yiv4332546053ygrp-mkp .yiv4332546053ad a 
{color:#ff;text-decoration:none;}#yiv4332546053 #yiv4332546053ygrp-sponsor 
#yiv4332546053ygrp-lc {font-family:Arial;}#yiv4332546053 
#yiv4332546053ygrp-sponsor #yiv4332546053ygrp-lc #yiv4332546053hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4332546053 
#yiv4332546053ygrp-sponsor #yiv4332546053ygrp-lc .yiv4332546053ad 
{margin-bottom:10px;padding:0 0;}#yiv4332546053 #yiv4332546053actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4332546053 
#yiv4332546053activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4332546053
 #yiv4332546053activity span {font-weight:700;}#yiv4332546053 
#yiv4332546053activity span:first-child 
{text-transform:uppercase;}#yiv4332546053 #yiv4332546053activity span a 
{color:#5085b6;text-decoration:none;}#yiv4332546053 #yiv4332546053activity span 
span {color:#ff7900;}#yiv4332546053 #yiv4332546053activity span 
.yiv4332546053underline {text-decoration:underline;}#yiv4332546053 
.yiv4332546053attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv4332546053 .yiv4332546053attach div a 
{text-decoration:none;}#yiv4332546053 .yiv4332546053attach img 
{border:none;padding-right:5px;}#yiv4332546053 .yiv4332546053attach label 
{display:block;margin-bottom:5px;}#yiv4332546053 .yiv4332546053attach label a 
{text-decoration:none;}#yiv4332546053 blockquote {margin:0 0 0 
4px;}#yiv4332546053 .yiv4332546053bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4332546053 
.yiv4332546053bold a {text-decoration:none;}#yiv4332546053 dd.yiv4332546053last 
p a {font-family:Verdana;font-weight:700;}#yiv4332546053 dd.yiv4332546053last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4332546053 
dd.yiv4332546053last p span.yiv4332546053yshortcuts 
{margin-right:0;}#yiv4332546053 div.yiv4332546053attach-table div div a 
{text-decoration:none;}#yiv4332546053 div.yiv4332546053attach-table 
{width:400px;}#yiv4332546053 div.yiv4332546053file-title a, #yiv4332546053 
div.yiv4332546053file-title a:active, #yiv4332546053 
div.yiv4332546053file-title a:hover, #yiv4332546053 div.yiv4332546053file-title 
a:visited {text-decoration:none;}#yiv4332546053 div.yiv4332546053photo-title a, 
#yiv4332546053 div.yiv4332546053photo-title a:active, #yiv4332546053 
div.yiv4332546053photo-title a:hover, #yiv4332546053 
div.yiv4332546053photo-title a:visited {text-decoration:none;}#yiv4332546053 
div#yiv4332546053ygrp-mlmsg #yiv4332546053ygrp-msg p a 
span.yiv4332546053yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv4332546053 
.yiv4332546053green {color:#628c2a;}#yiv4332546053 .yiv4332546053MsoNormal 
{margin:0 0 0 0;}#yiv4332546053 o {font-size:0;}#yiv4332546053 
#yiv4332546053photos div {float:left;width:72px;}#yiv4332546053 
#yiv4332546053photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv4332546053 
#yiv4332546053photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv4332546053
 #yiv4332546053reco-category {font-size:77%;}#yiv4332546053 
#yiv4332546053reco-desc {font-size:77%;}#yiv4332546053 .yiv4332546053replbq 
{margin:4px;}#yiv4332546053 #yiv4332546053ygrp-actbar div