Bom dia, Uma coisa que talvez o teu ambiente tenha de sobra, e já que está usando EE, pense em usar DOP (PARALLEL) para essas tabelas assim a consulta vai rodar mais rápido.
Dá uma lida no manual https://docs.oracle.com/cd/E11882_01/server.112/e25554/indexes.htm#sthref120 CREATE BITMAP INDEX sales_cust_gender_bjix ON sales(customers.cust_gender) FROM sales, customers WHERE sales.cust_id = customers.cust_id LOCAL NOLOGGING COMPUTE STATISTICS; OBS.: Lembrando que bitmap índexes tem que ser usados com muito cuidado, por conta de locks e que o paralelismo pode usar todos os recursos, verifique, monte um cenário de testes antes de aplicar isso em prod. OK? Atenciosamente, [RED] Rodrigo Mufalani - Dir. Técnico rodr...@mufalani.com.br +55 21 988 994 817 Mufalani +55 21 3193 0326 Rua Almirante Grenfall, 405, Bloco 3, Sala 310 Centro Empresarial Washington Luiz Duque de Caxias - RJ CEP 25085-009 www.mufalani.com.br<http://www.mufalani.com.br/> [id:image002.png@01D2F4C6.8E6B3BE0] De: <oracle_br@yahoogrupos.com.br> em nome de "Luis Freitas lfreita...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> Responder para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br> Data: sexta-feira, 15 de dezembro de 2017 12:09 Para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br> Assunto: Re: [oracle_br] Consulta muito lenta!! Rafael, Difícil sugerir alguma coisa só com o plano de execução, sem saber a cardinalidade campos usados na query. O tempo maior do plano está aparecendo como CPU, e está proximo do tempo que você reportou, algumas coisas que poderiam ser tentadas: - Forçar o uso de algum índice no campo RACCT, que é o numero da conta. Se houver uma cardinalidade grande nesse campo, pode reduzir muito o tempo de execução. - Forçar um full scan na FAGLFLEXA, o que deve mudar o perfil da query de CPU para disco. - Forçar um join por "nested loops", em vez de "hash". Também deve mudar o perfil de CPU para disco. Outra coisa que pode ser tentada é ativar o paralelismo na FAGLFLEXA, o que irá distribuir a execução da query em mais processos. Poderia ser feito por "sql plan management" para não ativar direto na tabela. Atc, Luis Freitas On Friday, December 15, 2017 10:57 AM, "Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> wrote: Senhores, bom dia. Preciso de uma grande ajuda dos especialistas. Ambiente single instance, file system, EE 11.2.0.3 Options: diagnostic and tuning pack, in memory, advanced compression, partitioning Possuo uma query do sistema SAP (standard SAP), ou seja, nao existe alternativa para mudança estrutural da consulta, nem por hint na consulta, nem nada, por ser standard. O que é possível fazer é tudo a nível de banco de dados, como criação de sql patch, rewrite etc... Pois bem, vamos aos detalhes: A consulta envolve 2 tabelas e 2 índices, cada um com seus respectivos tamanhos abaixo: tabela x1: 400GB tabela x2:160GB Indice tab x1: 140GB Indice tab x2: 2GB Duracao da consulta: 16 minutos OBS: Os segmentos envoldios nao possuem PARTICIONAMENTO ou COMPRESSAO. COnsulta abaixo: http://textuploader.com/dcreu Plano de execucao abaixo (SELECT * FROM table(dbms_xplan.display_cursor)): http://textuploader.com/dcre7 Alternativas 1: A criacao de uma Mview para a consulta em questao, porem o SAP nao pode direcionar o relatorio para a MVIew, entao pensei na rewrite para forcar ao ler o sqlid utilizar Mview, porem se as mview nao estiver totalmente atualizada com as tabelas envolvidas a Mview nao sera lida, ou seja, a tabela em questao possui 2 bilhoes de registros, eh alterada o tempo inteiro, ou seja, sem chance. Alternativa 2: realizar um compression OLTP nas tabelas envolvidas, o que acham? Problema sera a carga de DML nessas tabelas, me preocupo com a lentidao dos inserts, updates e deletes. Alternativa 3: Particionamento. Porem precisamos de uma solucao rapida, ira entrar um processo de auditoria e nao temos tempo para essa implementacao. Alguem pode ajudar nessa dificil missao? [As partes desta mensagem que não continham texto foram removidas]
