Chippa, Na verdade, se eu tomar esta atitude, eu iria deixar a tabela vazia pois segundo o desenvolvedor, ele não utiliza estas informações para nada, o driver coleta automaticamente. Eu vi em alguns fóruns um pessoal dizendo que fez isto também, pretendo utilizar como ultima alternativa esta saída. Estou aguardando a resposta do suporte Oracle, para ver o que les sugerem. Se chegarmos a algum ponto, compartilho com todos.
-- 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: "J. Laurindo Chiappa" <jlchia...@yahoo.com.br> Reply-To: <oracle_br@yahoogrupos.com.br> Date: terça-feira, 18 de junho de 2013 16:35 To: <oracle_br@yahoogrupos.com.br> Subject: [oracle_br] Re: Problemas de performance -Query ao DD. pmfji, Régis, mas vamos deixar CLARO que a sugestão do Ederson era algo a se fazer uma vez só, só para TESTAR se a questão se relacionava com a ALL_OBJECTS do banco : é CLARO que vc não pode simplesmente copiar a ALL_OBJECTS do SYS para um schema qualquer e achar que tudo vai funcionar permanentemente daí pra frente , pois (ÓBVIO) as tabelas internas do RDBMS Oracle podem ser atualizadas a Qualquer Momento, então em tese alguns minutos depois que vc copiou a ALL_OBJECTS pode Muito Bem ser que essa tua cópia já ficou DEFASADA por conta de alterações internas por parte do RDBMS, aí o driver vai receber metadados inválidos/diferentes do real, e isso pode dar Altas Confas, só.... Blz ??? []s Chiappa --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , Régis Pradela <pradelarf@...> escreveu > > 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 <ederson2001br@...> > Reply-To: <oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > > Date: terça-feira, 18 de junho de 2013 09:12 > To: <oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.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> <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] > [As partes desta mensagem que não continham texto foram removidas]
