Seguemn as respostas/comments para cada item : > > Onde eu escrevi DBA... os mesmos são responsáveis por ** toda ** a infra-estrutura dos ambientes de informática....
ohmygod, além de cuidar de banco, que normalmente já tem seus probleminhas. e de dar suporte/auxílio/mentoring em tecnologia de banco (não desenvolver, mas dar as dicas e estabelecer políticas) pros desenvolvedores/utilizadores, que é parte integrante de qquer dba (em diferentes porcentagens, mas enfim) os seus DBAs ainda cuidam de infra-estrutura ?? rapaaaz, eses merecem o que ganham :) > . A mim me parece que tais atribuições andam frequentemente juntas, mas no entanto peço desculpas se a regra de fato é que essa não é uma atribuição de um DBA. De modo algum desculpas são necessárias, só vejo como difícil um DBA normalmente já preocupado com tuning/segurança/backup/políticas de uso/monitoração e tudo o mais que um banco omplexo de Produção exige ter como fazer esse tipo e trabalho extra, mas se na sua empresa é assim, então tá.... Normalmente pelo que conheço não é tanto assim, por isso que sugeri que o DBAs não seriam o primeiro recurso a acionar... > > Eu de fato mesmo procurei pra ver se existiam documentos que referenciassem como esse timeout pudesse ser aumentado.... No entanto, como essa parte de configuração de ambiente e infra-estrutura não é especificamente minha praia, procurei o grupo em busca de respostas de profissionais mais ligados ao contexto. Foi esse meu intuito. OK, mas já que vc ** não ** disse explicitamente o que tinha feito, o que tinha lido, por isso indiquei a documentação : na bem da verdade, sempre que vc abrir uma thread no fórum, se vc já disser o que fez, o que leu, o resultado da sua tentativa em aplicar o que leu/estudou, coisas do tipo, isso SEMPRE adianta o expediente.... > > Quanto a otimização do relatório, o mesmo já foi otimizado o máximo possível e não estamos obtendo mais resultados significativos. Pra podermos dizer que realmente um SQL foi explorado ao máximo, vc ** REALMENTE ** aplicou os recursos "avançados" de SQL, tal como analytics, WITH clause, subquery factoring ?? Vc ** realmente **, junto com o DBA, testou a aplicação de planos alternativos, via hints ? Vc testou os alteradores de comportamento de um SQL via ALTER SESSION, tais como db_file_multiblock_read, OPTIMIZER_MODE, params controladores de SGA/PGA ?? VC desmontou o SQL ? Com "desmontar" quero dizer, normalmente num join há um conjunto restrito de tabelas que trazem o "core" dos dados, as outras trazem algum lookup, coisa do tipo : reduzir o SQL ao mínimo num primeiro momento tirando as tabs acessórias é uma técnica comum de estudo... Parallel SQL pode ser uma boa, ependendo do caso... Ebfim, para declarar um SQL como totalmente otimizado, ao menos essas coisas todas eu tentaria/pediria pra verificar junto com os DBAs.... > Views materializadas não se aplicam aqui devido ao fato da necessidade do relatório apresentar dados on-line. Aqui saímos do tuning de SQL em si e vamos para a área de melhoria de storage dos dados, mas é comum isso acontecer,uma pode influenciar a outra... ==> Primeiro, é Assertiva absolutamente *** FALSA *** essa de que VMs só servem para snapshot de dados com atraso, há anos vc já pode especificar um VM com REFRESH ON COMMIT, aí a vm é atualizada ONLINE, EM CONJUNTO com a tabela, representado os dados absolutamente REAIS e ÚLTIMOS da tabela... veja vc, com certeza se a massa de dados é grande vc NÂO DEVE estar lendo/apresentando linha a linha no seurelatório, FATALMENTE vc faz algum tipo de agrupação/contagem, yes ? A idéia da vm é vc ter uma vm ATUALIZADA, que já contenha a agrupação desejada, assim AO INVÉS DE vc ter que ler os não sei quantos milhões de linhas para descobrir o resultao, a vm JÀ CONTÉM o resultado prontinho.... NEM SEMPRE isso é totalmente possível, principalmente se o relatório é dinâmico e a cada vez o usuário quer agrupar por coisas diferentes, mas SE houver como se definir isso á priori, a vm é mão na roda total...Obviamente, além de tudo a vm é um objeto FÌSICO, que ocupa espaço, e além disso há um pequeno OVERHEAD pra que ela seja atualiada, mas de forma alguma elas deveriam ter sido descartadas e antemão, se o foram reveja isso, junto com o DBA...Eu digo DBA, porque normalmente é ELE quem conhece em profundidade os etups/privs/etc necessários para se usar uma dada feature. ==> Segundo, reforço aqui que além de evitar leitura para operações que vc já poderia saber a resposta com a vm, a outra idéia quando se fala em massa "estratosférica" é vc "separar" os dados que precisa : assim, se particionando os dados vc evitar ter que acessar N partições, ok... Ou ainda, tal como eu falei na msg anterior, índices condicionais podem ser uma boa : afinal, normalmente não são exatamente TODOS os dados da tabela-monstro X ou Y que vc quer, normalmente há uma flag ou alguma coluna com algum domínio especial que vc quer, ** SE ** vc criar um índice aonde só esses registros entrem puff, vc evitou um monte de I/O por linhas que ao final as WHEREs descartariam.... Num cliente anterior (por exemplo) numa tabela de dezenas de milhões era só umas poucas centenas de milhares que eu precisava acessar (de acordo com uma coluna de STATUS, com um domínio próprio) : o pessoal tinha criado um índice normal, não adiantou picas, pois um index range scan num índice de dezenas de milhões ainda é horroroso, daí eu criei um ídnice aonde só entravam os registros que eu queria e mandei brasa num index fast full scan desse índice (que ficou minúsculo), foi um susto pro pessoal a performance que deu... da mesma forma, Clusters, índices bitmap, star-joins, todos esses recursos podem providenciar algum "grau" de separação... > > Quanto a abordagem de rodar via job, parece interessante, mas pergunto: a funcionalidade web "schedularia" o job, que levaria em torno de 5 a 10 minutos para rodar... Como fazer para que depois desse tempo, o relatório seja disponibilizado para o utilizador? O que eu propus é : a tela que hoje dispara o reports diretamente passaria a, via DBMS_JOB, disparar uma PROCEDURE em background (assim a tela pode até ** DESCONECTAR ** do banco, evitando timeouts, poupando recursos !!), e essa procedure após preencher a tabela de resultados ela sinaliza esse término pra tela, que aí sim dispara o report, que como eu diosse vai ser rapidinho já que vai fazer só um SELECT * FROM tabeladeresultados.... Há n+1! maneiras de uma procedure se "comunicar" com um programa externo ao banco, uma low-tech poderia simplesmente ser que ela GRAVE um arquivo-texto via utl_file num local a que a tela do usuário possa ler em pooling, sendo que em modo web na verdade reside lá no servidor web, via de regra permissão/mapeamento de pastas entre duas máquinas não é problemático... Ou ainda, a procedure poderia popular uma linha duma tabela de jobs quando terminar, e a tela de usuário a cada minuto abre uma conexão, testa a tabela, se não existe evolve a conexão e "dorme" por mais um minuto, coisa assim... > ...No entanto, acaba dando timeout na página do navegador durante o processo de inserção dos dados via append na tabela de resultados... é óbvio, é o que eu falei acima, o truque é vc fazer o trabalho DENTRO do banco via job, não disparar de FORA via conexão externa que tem que ser mantida... Blz ? Bom, de modo geral, sem detalhar muito, é + ou - isso que eu queria dizer, espero que as idéias que te passei sejam de alguma forma úteis, esse é sempre o objetivo de todos aqui, bater papo, dar sugestões, dar dicas sobre tecnologia de banco de dados Oracle, é por aí... []s Chiappa =========================================================== Participe do ENPO - Encontro de Profissionais Oracle 2008 ! Informações e inscrições em http://www.enpo-br.org José Laurindo Chiappa, Palestrante ENPO-2008 ===========================================================
