Re: [oracle_br] Re: Views WRH$
Opa Chiappa, Falha minha. É gerado na SYSAUX mesmo. Obrigado pelas dicas. Abraços! Marcelo Medrado Polo-IT 2009/8/31 jlchiappa > > > Pra mim, o ** mais estranho ** é que vc diz que estão na tablespace SYSTEM > : normalmente o AWR é criado na tablespace SYSAUX... Bom, iirc vc não pode > sair truncando essas tabelas de acordo com o Suporte : elas contém snapshos > de AWRs, vc deve usar a package DBMS_WORKLOAD_REPOSITORY, que tem as rotinas > de DROP (de snapshots, de baselines, etc) apropriadas - tente lá, qquer > coisa se não conseguir diga EXATAMENTE quais são os objetos que ainda estão > "grandes" E é claro, se vc não quer usar o AWR (ou não pode porque não > tem Licença), deve usar a nota metalink "Package for disabling AWR without a > Diagnostic Pack license in Oracle", Doc ID: 436386.1 > > []s > > Chiappa > -- Em oracle_br@yahoogrupos.com.br , > Marcelo Medrado escreveu > > > > > Prezados, > > > > Estou enfrentando um problema numa base de dados 10g onde não possuo > acesso > > ao DBCONSOLE/GRID CONTROL. > > > > Existem tabelas WRH$ na tablespace SYSTEM que estão crescendo de forma > > acelerada e não sei: > > > > 1) Se posso remover diretamente (delete ou truncate) e em que ordem isso > > pode ser feito; > > 2) Se elas podem ser eliminadas/limpas através de algum DBMS_ da > vida; > > 3) Como fazer para que elas parem de crescer; > > > > Sei que elas pertencem ao AWR e já vi algumas documentações > (não-oficiais) > > mostrando que podemos truncá-las da mesma forma que fazemos com a AUD$. > > > > Alguém já teve esta experiência ou tem algo a comentar? > > > > Abraços, > > > > Marcelo Medrado > > Polo-IT > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Views WRH$
Pra mim, o ** mais estranho ** é que vc diz que estão na tablespace SYSTEM : normalmente o AWR é criado na tablespace SYSAUX... Bom, iirc vc não pode sair truncando essas tabelas de acordo com o Suporte : elas contém snapshos de AWRs, vc deve usar a package DBMS_WORKLOAD_REPOSITORY, que tem as rotinas de DROP (de snapshots, de baselines, etc) apropriadas - tente lá, qquer coisa se não conseguir diga EXATAMENTE quais são os objetos que ainda estão "grandes" E é claro, se vc não quer usar o AWR (ou não pode porque não tem Licença), deve usar a nota metalink "Package for disabling AWR without a Diagnostic Pack license in Oracle", Doc ID: 436386.1 []s Chiappa -- Em oracle_br@yahoogrupos.com.br, Marcelo Medrado escreveu > > Prezados, > > Estou enfrentando um problema numa base de dados 10g onde não possuo acesso > ao DBCONSOLE/GRID CONTROL. > > Existem tabelas WRH$ na tablespace SYSTEM que estão crescendo de forma > acelerada e não sei: > > 1) Se posso remover diretamente (delete ou truncate) e em que ordem isso > pode ser feito; > 2) Se elas podem ser eliminadas/limpas através de algum DBMS_ da vida; > 3) Como fazer para que elas parem de crescer; > > Sei que elas pertencem ao AWR e já vi algumas documentações (não-oficiais) > mostrando que podemos truncá-las da mesma forma que fazemos com a AUD$. > > Alguém já teve esta experiência ou tem algo a comentar? > > Abraços, > > Marcelo Medrado > Polo-IT > > > [As partes desta mensagem que não continham texto foram removidas] >
[oracle_br] Re: Segment SYS_LOB
Quanto ao "porque", não tem por onde, a alocação afaik é sempre feita por extents, talvez vc realmente tenha , como eu falei, extents de tamanho bem grande, aí a alocação de espaço sobe rapidamente, e à frente do consumo via INSERTs Cheque, e se for isso, e isso está te atrapalhando de alguma forma, é como eu falei, vc faz um MOVE qquer desses dadose recria as especificações de storage... o exp/imp sozinhos NÃo servem, vc teria que fazer um exp, extrair o DDL do objeto, DROPAR (com a opção de PURGE ao final!!) o objeto, alterar o DDL para que tenha extents, chunksize, etc, do jeito que vc quer (E pra tabelas de log eu certamente pensaria na hipótese de que o LOB ** vai ** pra tablespaces diferentes E teria o objeto com alocação de espaço MANUAL, sem ASSM, especificando PCTFREE 1 PCTUSED 99 pra nunca reservar espaço pra UPDATEs), recriar o objeto e aí sim importaros dados, ok ? []s Chiappa --- Em oracle_br@yahoogrupos.com.br, kolombesky marco escreveu > > Obriga, Chiappa !!! > > A tabela que o segmento se referencia é uma tabela de Log. > Fiz uma limpeza por data e a mesma está menor. > Mas o crescimento do segmento SYS_LOB dobrou em +- 10 dias, de 60GB para > 120GB. > > Eu preciso pelo menos descobrir o por que disto. > Vi que há opção do shrink para pelo menos normalizar o espaço usado pelo > segmento, caso eu faça um exp/imp desta tabela resolveria o problema tb ??? > > Obrigado. > > Att. > > Marco Aurelio Kolombesky > > --- Em seg, 31/8/09, jlchiappa escreveu: > > > De: jlchiappa > Assunto: [oracle_br] Re: Segment SYS_LOB > Para: oracle_br@yahoogrupos.com.br > Data: Segunda-feira, 31 de Agosto de 2009, 16:54 > > > > > > > afaik que eu saiba lob segments tem seu espaço controlado ** eaxatamente ** > como segmentos "normais", ie : uma vez alocado o espaço para o segmento, > absolutamente NÃO adianta vc fazer DELETE dos dados, o espaço CONTINUA > marcado como alocado : isso visa á performance, pois futuros INSERTs/UPDATEs > não precisariam formatar novos blocos, mas sim reusarão esse espaço que já > foi usado no passado pelos dados do segmento... Sendo assim, quando vc > REALMENTE precisar/desejar liberar o espaço não usado mas ainda alocado > (porque vc sabe com 100% de certeza que não mais virão INSERTs/UPDATEs no > futuro) , vc tem que MOVER o segmento, via ALTER TABLE move, INDEX rebuild, > DBMS_REDEFINE, etc, é isso. > E claro, o tamanho dos "pedaços" a serem usados pro LOB são definidos com o > parâmetro de CHUNK na definição do LOB e o extent size nos params de STORAGE > (ou automaticamente se for tablespace LMT sysallocated) , se essas definições > não estão satisfazendo antes de mover os dados REDEFINA o LOB... > > []s > > Chiappa > --- Em oracle...@yahoogrup os.com.br, kolombesky marco ...> escreveu > > > > Boa tarde !!! > > > > > > > > Gostaria de saber se há e como reduzir os tamanhos de segmentos SYS_LOB, > > sendo que já reduzi os dados da tabela que faz referencia a este segmento, > > hoje a mesma está utilizando quase 120GB. > > > > > > Obrigado. > > > > > > Att. > > > > Marco Aurelio Kolombesky > > > > > > _ _ _ _ _ _ > > Veja quais são os assuntos do momento no Yahoo! +Buscados > > http://br.maisbusca dos.yahoo. com > > > > > > > > > > > > > > > > > > > > > > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com > > [As partes desta mensagem que não continham texto foram removidas] >
Re: [oracle_br] Segment SYS_LOB
Boa tarde, Faça um export e um import dessa tabela em uma janela de manutenção. Atenciosamente, Rodrigo Mufalani OCP 11g & 10g +RAC Oracle ACE Member mufal...@oi.com.br http://mufalani.blogspot.com - Original Message - From: "kolombesky marco" To: Sent: Monday, August 31, 2009 2:41 PM Subject: [oracle_br] Segment SYS_LOB Boa tarde !!! Gostaria de saber se há e como reduzir os tamanhos de segmentos SYS_LOB, sendo que já reduzi os dados da tabela que faz referencia a este segmento, hoje a mesma está utilizando quase 120GB. Obrigado. Att. Marco Aurelio Kolombesky Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- >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/ -- >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
[oracle_br] Views WRH$
Prezados, Estou enfrentando um problema numa base de dados 10g onde não possuo acesso ao DBCONSOLE/GRID CONTROL. Existem tabelas WRH$ na tablespace SYSTEM que estão crescendo de forma acelerada e não sei: 1) Se posso remover diretamente (delete ou truncate) e em que ordem isso pode ser feito; 2) Se elas podem ser eliminadas/limpas através de algum DBMS_ da vida; 3) Como fazer para que elas parem de crescer; Sei que elas pertencem ao AWR e já vi algumas documentações (não-oficiais) mostrando que podemos truncá-las da mesma forma que fazemos com a AUD$. Alguém já teve esta experiência ou tem algo a comentar? Abraços, Marcelo Medrado Polo-IT [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Re: Segment SYS_LOB
Obriga, Chiappa !!! A tabela que o segmento se referencia é uma tabela de Log. Fiz uma limpeza por data e a mesma está menor. Mas o crescimento do segmento SYS_LOB dobrou em +- 10 dias, de 60GB para 120GB. Eu preciso pelo menos descobrir o por que disto. Vi que há opção do shrink para pelo menos normalizar o espaço usado pelo segmento, caso eu faça um exp/imp desta tabela resolveria o problema tb ??? Obrigado. Att. Marco Aurelio Kolombesky --- Em seg, 31/8/09, jlchiappa escreveu: De: jlchiappa Assunto: [oracle_br] Re: Segment SYS_LOB Para: oracle_br@yahoogrupos.com.br Data: Segunda-feira, 31 de Agosto de 2009, 16:54 afaik que eu saiba lob segments tem seu espaço controlado ** eaxatamente ** como segmentos "normais", ie : uma vez alocado o espaço para o segmento, absolutamente NÃO adianta vc fazer DELETE dos dados, o espaço CONTINUA marcado como alocado : isso visa á performance, pois futuros INSERTs/UPDATEs não precisariam formatar novos blocos, mas sim reusarão esse espaço que já foi usado no passado pelos dados do segmento... Sendo assim, quando vc REALMENTE precisar/desejar liberar o espaço não usado mas ainda alocado (porque vc sabe com 100% de certeza que não mais virão INSERTs/UPDATEs no futuro) , vc tem que MOVER o segmento, via ALTER TABLE move, INDEX rebuild, DBMS_REDEFINE, etc, é isso. E claro, o tamanho dos "pedaços" a serem usados pro LOB são definidos com o parâmetro de CHUNK na definição do LOB e o extent size nos params de STORAGE (ou automaticamente se for tablespace LMT sysallocated) , se essas definições não estão satisfazendo antes de mover os dados REDEFINA o LOB... []s Chiappa --- Em oracle...@yahoogrup os.com.br, kolombesky marco escreveu > > Boa tarde !!! > > > > Gostaria de saber se há e como reduzir os tamanhos de segmentos SYS_LOB, > sendo que já reduzi os dados da tabela que faz referencia a este segmento, > hoje a mesma está utilizando quase 120GB. > > > Obrigado. > > > Att. > > Marco Aurelio Kolombesky > > > _ _ _ _ _ _ > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbusca dos.yahoo. com > Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Segment SYS_LOB
afaik que eu saiba lob segments tem seu espaço controlado ** eaxatamente ** como segmentos "normais", ie : uma vez alocado o espaço para o segmento, absolutamente NÃO adianta vc fazer DELETE dos dados, o espaço CONTINUA marcado como alocado : isso visa á performance, pois futuros INSERTs/UPDATEs não precisariam formatar novos blocos, mas sim reusarão esse espaço que já foi usado no passado pelos dados do segmento... Sendo assim, quando vc REALMENTE precisar/desejar liberar o espaço não usado mas ainda alocado (porque vc sabe com 100% de certeza que não mais virão INSERTs/UPDATEs no futuro) , vc tem que MOVER o segmento, via ALTER TABLE move, INDEX rebuild, DBMS_REDEFINE, etc, é isso. E claro, o tamanho dos "pedaços" a serem usados pro LOB são definidos com o parâmetro de CHUNK na definição do LOB e o extent size nos params de STORAGE (ou automaticamente se for tablespace LMT sysallocated) , se essas definições não estão satisfazendo antes de mover os dados REDEFINA o LOB... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, kolombesky marco escreveu > > Boa tarde !!! > > > > Gostaria de saber se há e como reduzir os tamanhos de segmentos SYS_LOB, > sendo que já reduzi os dados da tabela que faz referencia a este segmento, > hoje a mesma está utilizando quase 120GB. > > > Obrigado. > > > Att. > > Marco Aurelio Kolombesky > > > > > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com >
[oracle_br] Segment SYS_LOB
Boa tarde !!! Gostaria de saber se há e como reduzir os tamanhos de segmentos SYS_LOB, sendo que já reduzi os dados da tabela que faz referencia a este segmento, hoje a mesma está utilizando quase 120GB. Obrigado. Att. Marco Aurelio Kolombesky Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com
[oracle_br] Re: Coleta de Estatísticas
Colega, vou fazer umas obs a respeito e tentar te dar umas dicas, mas isso tudo é ** rigorosamente ** documentado nos manuais de Administração e de Tuning, e (como complemento altamente indicado) nos livros "Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions", de Thomas Kyte (de forma geral, alguns pontos em diversos capítulos) e no "Cost Based Oracle: Fundamentals", de Jonathan Lewis (que é a "bíblia" do CBO, que é o assunto de que falamos quando se cita Estatísticas do tipo que vc cita). Se vc está perguntando os detalhes que pergunta, imagino que vc seja um DBA, então a leiturinha que te recomendei aí em cima é CRUCIAL, imho... Isso observado, lembrando que o que é possível aqui no Fórum é dar dicas gerais e não Consultorias avançadas, nem receita de bolo, seguem as minhas colocações : 1. 20 Gb não é grande nem aqui nem em Timbuctu, isso cabe no meu pen drive, num hardware de Produção isso não devia nem fazer cosquinha, vc devia conseguir coletar estatísticas em full duma coisinha assim em meia hora no máximo, coisa assim... 2. qual a importância da coleta de estatísticas para o banco? É o seguinte, se vc usar (como Recomendado no bd Oracle 10g e acima) a otimização de SQLs por Custo (CBO, Cost Based Optimizer), o banco vai usar informações estatísticas (como número de linhas, "ordenação" interna da tabela, repetição ou não dos valores presentes nas colunas, etc) para CALCULAR o melhor modo de acessar os dados, se usar ou não índice, qual índice usar, se ordenar ou não os dados cfrme lê, etc - SEM tais informações tudo vira um CHUTÃO, a taxa de erro nas otimizações vai pro espaço, é isso E não se pode esquecer que normalmente um banco de dados é DINÂMICO, as quantidades que existiam hoje amanhã ou depois podem mudar DRASTICAMENTE, então a coleta de informações estatísticas é algo constante, também 3. Como fazê-lo? Vc, como DBA, ** TEM que ** conhecer o banco, a aplicação, o "modo de uso" dos dados, para que quando houver alterações significativas nos dados, o mais imediatamente possível as estatísticas sejam coletadas, informando isso pro CBO... Veja que eu falei SIGNIFICATIVO, se vc tem uma tabela grande e alguém aumentou ou deletou uma ou duas linhas, NEM DE LONGE isso implica que imediatamente já tem que coletar estats. De um modo geral, só alterações de mais de 10% numa tabela (algo assim) é que se pode considerar significativo... O TIPO DE APLICAÇÃO que vc roda é determinante também : por exemplo, SE vc tiver uma aplicação tipo OLTP (ie, dezenas e dezenas, ou mesmo centenas de usuários cada um fazendo os seus pequenos SQLs) muito provavelmente deve demorar um pouco pra acumular uma quantidade significativa de alterações nos dados, e só algumas poucas tabelas de movimentação que alterariam, e normalmente mais durante o dia - num sistema desses vc tranquilamente poderia pedir toda noite pro banco MONITORAR e só coletar as estats que mudaram... Já SE o seu sistema for DW/batch (ie, poucos usuários mas fazendo SQLs enormes, entrada de dados também é monstruosa, milhares e milhares (ou milhões) de linhas carregadas a cada oprocessamento, aí já que tipicamente os dados são carregados via programa (não tem como um humano digitar esse volume) aí vc JÁ SABE quando deve coletar as estats, é imediatamente DEPOIS que o programa de carga roda... Claro que num volume alto assim talvez vc não consiga calcular em full, mas tirando uma boa amostra (sei lá, uns 20%, 30%, algo assim) via de regra já dá bem... 4. um ponto que vc tem que ter em mente é que há ** vários ** pontos do processo de coleta de estatística que são configuráveis (ie, se vc completa ou tira uma amostra, se monta ou não uma 'lista' com os valores sendo repetidos nas colunas (histograma), pra quais colunas monta o histograma, se deve ser usado SQL Paralelo (vários jobs slave pro mesmo comando)... No caso que vc pergunta, o que o dba_scheduler_job faz é chamar as rotinas apropriadas de coleta de estatística (package DBMS_STATS), mas sem especificar exatamente quais opções configuráveis usar, então o resultado é uma coleta "padrão", mínima, e com vários pontos "chutados", digamos assim : vc até pode alterar os defaults da dba_scheduler_jobs pra ver se aí ela te atende melhor Esse ponto é IMPORTANTE, se a coleta default feita pela Oracle não te atende MAS o seu banco é pequeno e simples, NÂO DEIXE de tentar alterar os defaults e a frequência pra ver se ela passa a te atender, mas em princípio isso funciona bem prum banco OLTP pequeno, com utilização "normal" (foi pra isso que a Oracle o inventou), MAS num banco produção pouquinha coisa mais complexo os defaults muitas vezes NÂO ATENDEM, e nem todos podem ser alterados, aí sim o procedimento é desabilitar a coleta default e criar uma rotina sua, sim No seu caso então, se vc desabilitou o dba_scheduler_jobs, deve criar uma rotina sua e mensurar/medir se teve melhora ou não.
[oracle_br] Coleta de Estatístic as
Olá a todos.
Talvez vocês achem estas perguntas absurdas mas gostaria de entender um pouco
mais sobre as estatísticas no banco.
Por exemplo, qual a importância da coleta de estatísticas para o banco?
Como fazê-lo?
Por exemplo, se eu tenho um banco relativamente grande (20GB) de dados, a
coleta demoraria, certo?
Como fazer corretamente esta coleta para determinado owner?
Criar um job para executar?
Como utilizar corretamente o comando "exec dbms_stats.gather_schema_stats"?
E como funciona o dba_scheduler_jobs? (Eu havia desabilitado o scheduler com o
comando "EXEC DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');"
São várias perguntas, mas todas relacionadas à coleta de estatísticas.
Preciso muito saber pois minhas consultas ao banco estão muito lentas, eu tinha
um job q estava executando durante o dia, antes era de noite, depois mudou para
o dia (???) "dbms_stats.gather_schema_stats('MEUSCHEMA');" e deixei para
executar nos finais de semana e talvez seja por isso que as consultas ficaram
lentas?
Meu banco Oracle 10gR2
Obrigado desde já.
Atenciosamente,
Alvaro
_
Você sabia que pode acessar o Messenger direto do seu Hotmail? Descubra como!
http://www.microsoft.com/brasil/windows/windowslive/products/tutoriais.aspx
[As partes desta mensagem que não continham texto foram removidas]
