Ederson, bom dia! Depois de muito pesquisar, realmente identifiquei que esta query é uma "*DES*inteligência" do driver ODBC. Eu encontre esta solução em um forum que você sugeriu, estou estudando se a mesma não tratá nenhum impacto no resto da aplicação. Consegui resolver o problema removendo as estatísticas do DD, o que fez com que a query executasse em 1ms, porem abri um chamado na Oracle para tentar resolver isto de outra maneira.
Grato pela ajuda! -- R.P. DBA Oracle Blog: www.rpradela.com.br Oracle Database 11g Administrator Certified Professional Oracle Database 11g Administrator Certified Associate Oracle Database 10g Real Applications Clusters Administrator Certified Expert (OCE) Oracle Enterprise Linux Certified Implementation Specialist (OCE) Oracle Database 11g Data Warehousing Certified Implementation Specialist Oracle Exadata 11g Certified Implementation Specialist From: ederson2001br <ederson200...@yahoo.com.br> Reply-To: <oracle_br@yahoogrupos.com.br> Date: terça-feira, 18 de junho de 2013 09:12 To: <oracle_br@yahoogrupos.com.br> Subject: [oracle_br] Re: Problemas de performance -Query ao DD. Bom dia Régis, Comigo já aconteceu exatamente o cenário que o Chiappa descreveu. Alguns SQLs sendo disparados pela camada de conexão e que eram insistentemente executados. Como eu não podia atualizar o ODBC da aplicação no cliente e nem modificar o código do sistema terceirizado, fiz o seguinte teste para evidenciar se o problema era a aplicação não homologada para aquele ambiente ou problema causado por contenção de objetos: -Criei uma tabela LOCAL no usuário da aplicação assim: create table all_indexes as select * from sys.all_indexes; Evidente que ao criar uma tabela local, ela tem prioridade sobre o sinônimo público. Desta forma, não houve mais contenção e o sql da camada de conexão era executado de imediato. Conclusão: investigar contenção de objetos e demais waits. Como o seu caso é um RAC, minha sugestão é que vc investigue também os eventos do tipo "GC CR Request". Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 ------------ Labor improbus omnia vincit --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , "R P" <pradelarf@...> escreveu > > Senhores, boa noite! > > Estou com um problema de performance após uma migração de 10gr2 (10.2.0.5) SE Linux, para 11gr2 (11.2.0.3.6) EE Linux, ambos RAC. > Ocorre que identifiquei a seguinte query sendo executada milhares de vezes pelos usuários, e esta query está tomando quase 80% do tempo do banco de dados, os desenvolvedores disseram que esta query não faz parte de aplicação, segue: > > SELECT * > FROM (SELECT NULL table_catalog, > idx.table_owner table_schema, > idx.table_name table_name, > NULL index_catalog, > idx.owner index_schema, > idx.index_name index_name, > NULL primary_key, > Decode(idx.uniqueness, 'UNIQUE', 65535, > 0) unique_, > Decode(idx.index_type, 'CLUSTER', 65535, > 0) CLUSTERED, > NULL type, > NULL fill_factor, > idx.initial_extent initial_size, > NULL nulls, > NULL sort_bookmarks, > 65535 auto_update, > 2 null_collation, > col.column_position ordinal_position, > col.column_name column_name, > NULL column_guid, > NULL column_propid, > 1 collation, > NULL cardinality, > NULL pages, > NULL filter_condition, > Decode(idx.index_type, 'CLUSTER', 65535, > 0) integrated > FROM all_indexes idx, > all_ind_columns col > WHERE idx.owner = col.index_owner > AND idx.index_name = col.index_name > AND idx.table_owner = col.table_owner > AND idx.table_name = col.table_name) indexes > WHERE table_schema = 'schema' ==> Owner > AND table_name = 'table1' ==> tabela app > ORDER BY 8, > 10, > 5, > 6, > 17 > O nome da tabela as vezes altera. > Busquei no google, e encontrei algumas reclamações sobre esta query, porem não ficou claro de onde ele vem. > Alguém sabe me dizer o que gera esta query? > > Para informação, a migração de versão e edição foi realizada via conversão de DD. > > -- > R.P. > DBA Oracle > Blog: www.rpradela.com.br > > Oracle Database 11g Administrator Certified Professional > Oracle Database 11g Administrator Certified Associate > Oracle Database 10g Real Applications Clusters Administrator Certified Expert (OCE) > Oracle Enterprise Linux Certified Implementation Specialist (OCE) > Oracle Database 11g Data Warehousing Certified Implementation Specialist > Oracle Exadata 11g Certified Implementation Specialist > [As partes desta mensagem que não continham texto foram removidas]