Menu de navegação

[CBizzarriParticipante]

Tenho o select abaixo para quantificar I/O no meu banco

select sql_text,disk_reads from (select sql_text,disk_reads,DENSE_RANK( ) OVER(order by disk_reads desc) disk_reads_rank from v$sql) where disk_reads_rank <=5;

. . uma as instruçoes retornadas é esta, precisa mata-la, mas nao consigo. . nao tem ninguem executando-a, nao tem jobs nem schedullers no banco . . COMO ESSA PRAGA(estatisticas) PODE EXECUTAR TODO SANTO DIA !??

[b]BEGIN DBMS_STATS.GATHER_TABLE_STATS (OWNNAME => ‘”SAPDEV”‘, TABNAME => ‘”TST03″‘, ESTIMATE_PERCENT => 15, METHOD_OPT => ‘FOR ALL COLUMNS SIZE 1’, DEGREE => NULL, CASCADE => TRUE, NO_INVALIDATE => FALSE); END;
190831169 [/b]

Obrigado !!!! 🙂

[CBizzarriParticipante]

➡ . .da pra confiar nesse select ??? 😯 . .da onde ta ressucitando essa DBMS !?? Valeu galera !!

[vieriParticipante]

Estatística não é praga.
Vc não tem que matar a coleta.

Você simplesmente tem que procurar outra coisa pra fazer, porque oque vc está fazendo é qualquer coisa menos administrar Oracle. 😡

risos..

brincadeira a parte!

Até que sua query é boa, mas no 10G o default é coletar automáticamente
as estatísticas das tabelas que tiveram X% dos dados alterados.

Caso verificar essa query entre as top de I/O te incomoda tanto
desabilite a coleta.

exec dbms_scheduler.disable(’GATHER_STATS_JOB’);

select state from dba_scheduler_jobs where job_name = ‘GATHER_STATS_JOB’;

Mas crie uma coleta adequada em seguida, porque vc pode daqui algum tempo você pode ser acusado de lentidão na base.

[CBizzarriParticipante]

. .é que no caso o banco é usado para SAP e ja existem jobs(para as DBMS_STATS) da SAP criados que rodam semanalmente com estimate legal, . .e o que achei esquisito foi o estimate que em muitos casos que vi, nao passava de 3% . .e imaginei que colher estatisticas assim, mais atrapalharia o otimizador que o ajudaria !!
[b]
Obrigado pela dica, li em algum lugar que o 10g fazia isso, mas nao tinah certeza 😀 valew Vieri !![/b]

[Autor]

Posts