Chiappa.Gostei desta regra de ouro.Hoje mesmo estava explicando para uma desenvolvedor estes conceitos,tem uma procedure de carga do SAP que demora horas e horas,como cheguei na empresa na segunda-feira ainda estou levantando informações,fazendo o reconhecimento de campo nos servidores de banco dados e etc. Mas fiz uma análise nas 2 procedures e encontrei relamente pontos a melhorar de cara.
-Uso desnecessário de ORDER BY. - Uso de cursor/loop em todos as queries - Poderia usar bulk,uso de limit no bulk.já que o processo é selecionar e inserir somente.ou inser select -- o commit periódico é uma aberração,a pessoa nem testou,não acreditei.Rodar roda,mas nunca termina rs. - Várias,mais várias variáveis declaradas e não usadas.Tem até algumas que são atribuidas valor e nunca se faz nada com isso."Código porquinho mesmo,copiado sem noção e colado". Gostei do termo "regra de ouro" ,posso usá-la com nas situações necessárias?rs é sempre bom mostrar estes conceitos ,desta forma que vocÊ passou. ótimo. Abs, Vlw, JC 2009/5/27 jlchiappa <[email protected]> > > > Não vai rolar, não, afaik André : Marcos, a questão número 1 é de conceito, > que o índice de função só tem a função executada (e portanto é atualizado) > só na hora do DML, então ** não ** faz muito sentido se querer usar > data/hora ou alguma informação que muda "sozinha", sem DML na tabela-origem, > como é o caso do TEMPO, que avança e muda sem que hajam DMLs, OU informação > que está em outra tabela, ok ? Pelo que eu entendo, vc vai usar a função num > SQL tipo : > > SELECT ... FROM outratabelaquenãoausadanafunção X > WHERE FUNCAO_USUARIO (X.ID, X.DT_REFERENCIA) = valorqueindicapresença > > certo ? Num caso desses, DMLs na tabela tabela_exemplo usada na função VÃO > ocorrer e (óbvio) não vão atualizar a tabela outratabelaquenãoausadanafunção > , simplesmente Não ROLA, não faz sentido... > > A segunda coisa é : ** please **, please, se vc quer máxima performance > pelo amor de qquer coisa Não Use funções PL/SQL no meio dos seus SQLs como o > exposto acima, isso ** TEM ** um custo em performance que normalmente não é > zero, pelo seguinte : > > a) vc está causando um CONTEXT SWITCH, o banco ** tem ** que "pular" do SQL > engine para o PL/SQL engine, isso não é de graça > > b) cardinalidade : o coitado do CBO **** NÂO TEM COMO **** "adivinhar" que > a sua função vai retornar só uma linha, então a estimativa dele de custo vai > ser TOTALMENTE na base do chute - já se vc tiver uma constraint de PK, e/ou > um índice unique em (ID, DT_REFERENCIA) com uma construção do tipo : > > SELECT ... FROM outratabelaquenãoausadanafunção X, > tabelaexemplo Y > WHERE Y.id_fk = X.ID > AND Y.dt_data = X.DT_REFERENCIA > AND Y.id_fk = :pID > AND Y.dt_data = :pDT_REFERENCIA > AND X.ID = :pID > AND X.DT_REFERENCIA = :pDT_REFERENCIA; > > aí SIM o CBO tem a informação necessária para concluir que vc está passando > a chave completa E portanto a junção retorna só uma linha.... Esconder > informação do CBO é muitas vezes QUEBRAR as pernas do coitado... > > Isso que eu falei ** não é ** novidade, pesquise em > http://asktom.oracle.com por CONTEXT SWITCH e por USER FUNCTION > CARDINALITY que vc vai achar n+1! referencias sobre isso... A regra de ouro > pra performance é CLARA : > > a) fazer pesquisas e manipulação de dados NUM ÚNICO SQL > b) se REALMENTE não der pra seguir a), ter POUCOS SQLs executados numa > transação, mas sem cursor/loop > c) se REALMENTE não der pra seguir b), usar BULK COLLECT e array processing > em PL/SQL > d) se REALMENTE não der pra seguir b), usar C ou java > > []s > > Chiappa > > --- Em [email protected] <oracle_br%40yahoogrupos.com.br>, > Andre Santos <andre.psantos...@...> escreveu > > > > > Marcos > > > > Neste caso, a sua função na realidade é uma "query"... > > Talvez você possa fazer um "join" ao invés de usar essa função. > > > > Já criei índices baseados em função, mas foram sempre para funções com um > > algoritmo (cálculo, por exemplo). > > Nunca tentei fazer um FBI com uma função que retornasse o resultado de > uma > > consulta... não sei se a opção DETERMINISTIC funcionaria nesse caso. Você > já > > testou? Se testou, qual foi a mensagem de erro? > > > > [ ] > > > > André > > > > 2009/5/25 Marcos Grimm <marcosgr...@...> > > > > > > > > > > > > Boa tarde pessoal, > > > > > > Meu nome é Marcos Grimme sou participante do grupo faz algum tempo já, > mas > > > sempre fico apenas observando as treads que acontecem. > > > > > > Eis que chegou o dia que eu mando aqui um problema que estou > enfrentando: > > > > > > Estou escrevendo uma query SQL que possui várias funções PL/SQL criadas > por > > > mim, por exemplo > > > > > > FUNCTION FUNCAO_USUARIO ( > > > pID VARCHAR2(5), > > > pDT_REFERENCIA DATE > > > ) > > > RETURN VARCHAR2 (5) > > > > > > IS > > > vRETORNO VARCHAR2(5); > > > BEGIN > > > SELECT id_coluna INTO vRETORNO FROM tabela_exemplo WHERE id_fk = pID > AND > > > dt_data = pDT_REFERENCIA; > > > RETURN vRETORNO; > > > END; > > > > > > Existe alguma maneira de eu criar um índice que funcione corretamente > com > > > essa função? Esse segundo parâmetro de data, como trabalho com ele > dentro > > > de > > > um índice? A opção DETERMINISTIC não serve, pois os resultados podem > mudar > > > dependendo do parametro de data passado. > > > > > > Se alguem puder ajudar vou ser muito grato. > > > > > > Atenciosamente, > > > Marcos Grimm > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > -- Júlio César Corrêa IS Technologist - Oracle DBA www.dbajccorrea.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University [As partes desta mensagem que não continham texto foram removidas] ------------------------------------ -------------------------------------------------------------------------------------------------------------------------- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/[email protected]/ -------------------------------------------------------------------------------------------------------------------------- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ ------------------------------------------------------------------------------------------------------------------------ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [email protected] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
