Chiappa, sou novo no Oracle, e vi que vc comentou na msg abaixo que tem outros 'scripts tradicionais ' para medir performance , índices fragmentados etc... vc teria ou se outra pessoa tiver na lista poderia estar disponibilizando para estar dando uma estudada e ja ir montando um acervo de scripts úteis do oracle ? vlw
----- Original Message ----- From: jlchiappa To: oracle_br@yahoogrupos.com.br Sent: Friday, December 01, 2006 6:26 PM Subject: [oracle_br] Re: db_keep_cache_size Thiago, sorry, mas pra fazer um trabalho mais que ** minimamente ** completo, vc deveria SIM ter ao menos um ** mínimo ** conhecimento do negócio, do aplicativo em execução, se não vc vai acabar dando uns chutões e tendo que fazer um monte de testes, que podem ou não dar certo... Aliás, é por isso que imho uma Empresa que não tem (por qquer motivo) um DBA próprio e usa serviço terceirizado, deveria AO MENOS exigir que esse DBA terceiro visite-a ao menos umas duas vezes pro semana E que seja sempre o mesmo, aí naturalmente ele vai absorvendo os conhecimentos (mínimos que sejam) do aplicativo, do negócio, senão fica um trabalho mais ou menos.... Mas voltando ao caso em questão : já que vc não sabe, vc VAI TER QUE levantar a info desejada, voltando VÁRIAS vezes à esse cliente e procurando no banco, e NÃO, "tabelas com mais FTS na SGA" não tem NADA A VER, como eu disse o objetivo aqui é localizar as tabelas ACESSADAS frequentemente (não importando se por FTS ou o que for), mas que também são relativamente "pequenas"... Pra vc saber a "popularidade" de uma tabela, seria bem mais fácil se vc tivesse uma noção do aplicativo, de como ele usa as tabelas, mas já que não tem, vc vai consultar (repetidas e repetidas vezes, em ocasiões DIFERENTES) as infos do banco e palpitar em cima, poderia ser algo + ou - tipo o abaixo, provavelmente só alterando pra não virem objetos do SYS, que são internos portanto não interessam, vc é proibido de mexer neles, E talvez especificando um OWNER, se vc sabe quem é o owner das tabelas : -- este te diz os 100 mais acessados select * from (SELECT substr(B.OBJECT,1,20) object, B.TYPE,COUNT(*) from v$session a, v$access b where a.sid = b.sid AND B.TYPE='TABLE' GROUP BY B.OBJECT,B.TYPE ORDER BY COUNT(*) ) where rownum < 100; -- este te diz qu tipo de acesso está tendo... COLUMN obj FORMAT a45 select CTYP Command , OBJ , 0 - EXEM EXES from (select distinct EXEM, CTYP, OBJ from ( select decode (S.COMMAND_TYPE , 2, 'Insert into ' , 3, 'Select from ' , 6, 'Update of ' , 7, 'Delete from ' ,26, 'Lock of ') CTYP , O.OWNER || '.' || O.NAME OBJ , sum(0 - S.EXECUTIONS) EXEM from V$SQL S , V$OBJECT_DEPENDENCY D , V$DB_OBJECT_CACHE O where S.COMMAND_TYPE in (2,3,6,7,26) and D.FROM_ADDRESS = S.ADDRESS and D.TO_OWNER = O.OWNER and D.TO_NAME = O.NAME and O.TYPE = 'TABLE' group by S.COMMAND_TYPE , O.OWNER , O.NAME ) ) ; -- este te dá uma idéia de como estão sendo usados select * from (select owner, object_name, statistic_name, value from v$segment_statistics order by value) where rownum < 500; ==>> junto com estes vc rodaria os scripts tradicionais (que acredito que, claro, vc já tem) que consultam as V$SQL e te dizem os SQLs mais populares, mais custosos, logicamente vc não só iria colocar em cache separado as tabelainhas populares MAS que participam de algum SQL popular e/ou custoso, senão o ganho líquido pro seu cliente vai ser minúsculo, óbvio.... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, thiagomz <[EMAIL PROTECTED]> escreveu > > Chiappa, > > O problema é que eu trabalho em uma consultoria, e quase nunca conheco o > negocio (tabelas), etc... > Neste ambiente, custumo usar o script Plan9i.sql do Donald K. Burleson > para eu saber quais sao as tabelas com mais FTS na SGA e pelo nro de > blocos, eu as classifico e vejo se posso usar o keep e recycle. > > O que vc sugere ? > > Thiago M. Zerbinato [thiagomz] > OCP DBA > --- > http://thiagomz.hpg.com.br > > > > > > jlchiappa wrote: > > A decisão de QUAIS tabelas separar em pools diferentes ** não é ** > > uma decisão física em grande parte, é LÓGICA, é VOCÊ que conhece o > > sistema e portanto sabe (ou ao menos tem uma idéia :) de QUAIS > > tabelas são relativamente pequenas MAS são frequentemente acessadas, > > e portanto valem a pena ser mantidas em keep, e informação do tipo > > NÂO fica no banco Oracle, fica só na sua cuca, ao ao menos na do > > analista/dono do sistema... Scripts do tipo o que vc apresenta podem > > te ajudar a ter uma idéia geral , mas : > > > > ==> só vc sabe se o limite de "pequeno" que o script usa é o seu, > > > > e o + importante, > > > > ==> só vc sabe, COMO EU DISSE acima, a regra do negócio, a utilização > > típica de cada tabela, pra poder julgar SE e QUAIS das tabs pequenas > > levantadas (por vc ou por script) se beneficiariam dum keep... Óbvio, > > tabelas pequenas mas RARÍSSIMAMENTE consultadas não faz sentido ter > > em cache... > > > > Quanto ao tamanho, é : uma vez levantadas e escolhidas mais ou menos > > as principais tabelas que vc acha que se beneficiariam, veja a > > quantidade total de blocos que eleas estão ocupam, tente criar o keep > > pool ao menos com esse tamanho mais alguma folguinha pro futuro... E > > claro, keep e recycle deveriam ser uma FRAÇÃO da default, que é onde > > a maioria dos objs fica... > > > > É claro, coisas desse tipo vc vai fazer SE e APENAS SE vc tem mémória > > e CPU sobrando, lógico - alocar RAM pra pools extras (que NUNCA será > > compartilhada pra outra coisa, SGA é assim) quando a RAM está no > > gargalo e pode faltar pra processos de usuários, PGA e outras, NÂO É > > uma coisa adequada... > > > > []s > > > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, thiagomz <thiagozerbinato@> > > escreveu > >> Pessoal, > >> > >> Seguindo a Nota *Note:223299.1 - **"Top Oracle 9i init.ora > > Parameters > >> Affecting Performance", **fui atrás do parametro > > db_keep_cache_size, > >> usando o script abaixo, notei que tenho algumas tabelas candidatas > > ao > >> keep_pool, dúvida, > >> > >> Como estimo o tamanho iniciar da keep_pool ? > >> > >> Referencia: > >> http://www.dba- > > oracle.com/t_script_automate_keep_pool_tables_indexes.htm > >> -- > >> > >> set pages 999 > >> set lines 92 > >> > >> spool keep_syn.lst > >> > >> drop table t1; > >> > >> create table t1 as > >> select > >> o.owner owner, > >> o.object_name object_name, > >> o.subobject_name subobject_name, > >> o.object_type object_type, > >> count(distinct file# || block#) num_blocks > >> from > >> dba_objects o, > >> v$bh bh > >> where > >> o.data_object_id = bh.objd > >> and > >> o.owner not in ('SYS','SYSTEM') > >> and > >> bh.status != 'free' > >> group by > >> o.owner, > >> o.object_name, > >> o.subobject_name, > >> o.object_type > >> order by > >> count(distinct file# || block#) desc > >> ; > >> > >> select > >> 'alter '||s.segment_type||' '||t1.owner||'.'||s.segment_name||' > >> storage (buffer_pool keep);' > >> from > >> t1, > >> dba_segments s > >> where > >> s.segment_name = t1.object_name > >> and > >> s.owner = t1.owner > >> and > >> s.segment_type = t1.object_type > >> and > >> nvl(s.partition_name,'-') = nvl(t1.subobject_name,'-') > >> and > >> buffer_pool <> 'KEEP' > >> and > >> object_type in ('TABLE','INDEX') > >> group by > >> s.segment_type, > >> t1.owner, > >> s.segment_name > >> having > >> (sum(num_blocks)/greatest(sum(blocks), .001))*100 > 80 > >> ; > >> > >> > >> spool off; > >> > >> ** > >> * > >> > >> -- > >> Thiago M. Zerbinato [thiagomz] > >> OCP DBA > >> --- > >> http://thiagomz.hpg.com.br > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________________ > >> Você quer respostas para suas perguntas? Ou você sabe muito e quer > > compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! > >> http://br.answers.yahoo.com/ > >> > > > > > > > > > > Apostilas » Dicas e Exemplos » Funções » Mundo Oracle » Package » Procedure » Scripts » Tutoriais acesse: http://www.oraclebr.com.br/codigo/ListaCodigo.php > > ---------------------------------------------------------- -------------------------------------------------------- > > 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/oracle_br@yahoogrupos.com.br/ > > ---------------------------------------------------------- -------------------------------------------------------- > > O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ > > ---------------------------------------------------------- ------------------------------------------------------ > > Links do Yahoo! Grupos > > > > > > > > __________ Informação do NOD32 IMON 1893 (20061130) __________ > > > > Esta mensagem foi verificada pelo NOD32 sistema antivírus > > http://www.eset.com.br > > > > > > > > > _______________________________________________________ > O Yahoo! está de cara nova. Venha conferir! > http://br.yahoo.com > [As partes desta mensagem que não continham texto foram removidas]
