Re: [oracle_br] Re: Performance em Query - Evento de Espera - PX Deq: Execute Reply

[Rodrigo Telles]

Obrigado Chiappa,
vou estudar os docs que me passou.

Abs


On 3/21/08, jlchiappa <[EMAIL PROTECTED]> wrote:
>
>   Colega, o documento que vc quer é a nota 280939.1, Subject:Checklist
> for Performance Problems with Parallel Execution , lá vc verá que até
> há algumas coisinhas que vc pode verificar, mas ela mesma (e as notas
> para as quais há link dentro dela), outras notas relacionadas como a
> 203238.1 Subject:Using Parallel Execution, a documentação mesmo
> (manuais oficiais Oracle do banco, nos itens inicados pela nota
> 184417.1 Subject: Where to find Information about Parallel Execution
> in the Oracle Documentation, todas dizem o mesmo basicamente :
>
> 1. cada um dos parallel Slaves fazem um pedaço da leitura que o SQL
> da sessão master lhe pediu, então ** SE ** a o SQL em si na sessão
> master está ruim, está acessando muitas coisas que não precisa, está
> usando um método de join ineficiente, etc, os slaves vão fazer
> TONELADAS de trabalho inútil, o primeiro passo sempre, SEMPRE, **
> SEMPRE **, é tunning do SQL, para que ele faça o menor número possível
> de LIOs, ok ?
>
> 2. já que os parallel slaves fazem I/O numa parcela do total, opções
> que segreguem parte do todo (como PARTICIONAMENTO) são absolutamente
> críticas para a performance deles. Da mesma forma o é o ajuste do I/O
> (tanto dentro do banco, com params de multiblock_read e de
> filesystem_options) quanto FORA do banco, no servior, setando onde
> possível I/O asíncrono, I/O direto, params de I/O (** vitais no
> unix/linux).
>
> ==> então a minha recomendação é : se não o fez ainda, *** PRIMEIRO
> *** vá pro tunning do SQL, melhorias das estruturas de dados (com
> paralelismo, índices seletivos, global temporary tables, modo
> nologging aonde/se possível, etc), e pra verificação de I/O no banco
> e no servidor, apenas ** SE ** não obter nada significativo aí sim vá
> pro micro-tunning como é o caso de params de parallel... Isso porque,
> tal como as notas metlink citadas falam, esses ajuste são CUSTOSOS,
> baseados muito em tentativa e erro, e ao final talvez não tragam nada
> de significativo
>
> []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
> ===
>
> --- Em oracle_br@yahoogrupos.com.br ,
> "Rodrigo Telles"
> <[EMAIL PROTECTED]> escreveu
> >
> > Pessoal,
> > estou com uma query que , em seus eventos de espera, tenho o evento
> *PX Deq:
> > Execute Reply* como o maior.
> >
> > Evento
> > Total_Waits
> > Total_TimeOuts
> > Time_Waited
> >
> >
> >
> >
> > SQL*Net more data from client
> > 1
> > 0
> > 0
> > PX Deq: Join ACK
> > 4
> > 0
> > 0
> > PX Deq: Parse Reply
> > 4
> > 0
> > 2
> > SQL*Net message to client
> > 15
> > 0
> > 0
> > SQL*Net message from client
> > 15
> > 0
> > 31
> > latch free
> > 17
> > 14
> > 8
> > PX Deq Credit: send blkd
> > 1738
> > 0
> > 175
> > PX Deq: Execute Reply
> > 1954
> > 1597
> > 316325
> > PX Deq Credit: need buffer
> > 9029
> > 0
> > 338
> > db file scattered read
> > 14892
> > 0
> > 18049
> > db file sequential read
> > 19486
> > 0
> > 15048
> >
> > Em doc da Oracle esse evento é visto como idle event. Porém se o
> tempo dele
> > for muito grande com relação aos outros devemos investigar os processos
> > paralelos escravos. Olhando cada um, que são 4, verifiquei que o maior
> > evento em espera são:*PX Deq Credit: send blkd e PX Deq: Table Q Normal*
> > Aqui temos um ambiente de DW e o Oracle é o 9.2.0.5
> >
> > Alguém ja passou por essa situação e conseguiu diminuir esses eventos de
> > espera? Além disso, a Oracle fala muito em investigar os processos
> paralelos
> > escravos? Existe algum lugar que mostre como investigar isso a fundo
> > verificando se eles estão ou não trabalhando com boa performance?
> >
> > Sds
> >
> > Rodrigo
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
> 
>


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Baixa performance no FETCH dentro de PL/SQL

[Rodrigo Telles]

Pessoal,
meu problema é o seguinte:
Tenho uma query que é executada quase que imediatamente(menos de 1 segundo)
se for executada no SQL/PLUS. E tenho a mesma query dentro de uma package
que começou a ter degradada sua performace após uns problemas de infra. Ao
debugar a package vejo que o gargalo é no comando FETCH. Ele demora em torno
de 6 minutos para executar.

Vcs ja passaram por isso? Ter uma query que roda rápido adhoc e dentro de um
PL demorar minutos?

O ambiente é AIX e Oracle 8.1.7.4.

Sds
Rodrigo


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] MAXSETSIZE - RMAN

[Rodrigo Telles]

Pessoal,
Tenho um banco com a política de backup implementada via RMAN

Está tudo correndo muito bem porém tenho observado um comportamento estranho
que não é o que a documentacao da Oracle fala.

Seguinte: Dentro do run{} eu tenho no script do BACKUP DATABASE a cláusula
de MAXSETSIZE=90G. Ele compila normal e executa porém ao final do backup eu
vejo que foram criados backupsets de até 150GB, ou seja, o Oracle ignorou a
cláusula que restringe o tamanho máximo de cada backupset.

Alguem já passou por isso?. Tem ideia se existe algum outro parâmetro para
setar!!!

Sds

Rodrigo Telles


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Enterprise Manager 10R2 - Cluster RH4L

[Rodrigo Telles]

Pessoal,
tenho um ambiente, ainda em teste, com duas máquinas, de hostname bd1 e bd2,
com RH4L e Oracle 10R2.

Estamos usando essas duas máquinas ligadas em um array de discos e
conectadas via o CLUSTER SWITCH do RH.
Nosso objetivo é ter uma máquina em produção e em caso de alguma falha com
ela o cluster do RH4L faz o switch  para a outra.

O binário do Oracle 10g e todos os datafiles estão no array.

Minha dúvida é a seguinte: Quando eu crio um banco executando o dbca pela
máquina bd1 eu seto que esse banco será gerenciado pelo EM CONTROL. Até aí
tudo bem. Depois de instalado eu consigo executar "emctl start dbconsole"
e acessar o EM via http://bd1:1158/em normalmente. Porém quando eu faço o
switch e levanto o banco na máquina bd2 eu não consigo executar "emctl start
dbconsole". Ele procura um arquivo de configuração que pelo que eu notei
depende do nome do host atual(bd2) e como o banco foi criado pela outra
maquina(bd1) o arquivo tem em seu nome o nome do host da outra máquina(bd1).


Nesse meu ambiente, qual seria a solução, tendo duas máquinas, uma ativa e
outra inativa para switch e um banco em comum, eu poder utilizar o EM
normalmente independente da máquina bd1 ou bd2 estar ativa?  Devo utilizar o
EM GRID CONTROL?

Sds

Rodrigo


[As partes desta mensagem que não continham texto foram removidas]

Re: [oracle_br] Re: DATA GUARD - SINCRONISMO - LOGICAL STANDBY

[Rodrigo Telles]

Jonathan,
obrigado pela resposta.
Mais uma pergunta: Se não é possivel fazer isso no 9i entao qual a diferenca
de usarmos o ARCH ou LGWR para transportar os redos para o STANDBY?.

Se em ambos os casos é necessário o SWITCH LOGFILE do PRIMARY para a
informação chegar ao STANDBY não vejo diferença alguma. E tb não vejo
acontecer o que o MANUAL da oracle fala. Que se colocarmos em o PRIMARY com
LWGR SYNC AFFIRM a transação dele so sera comitada e liberada somente quando
ela tiver sido escrita no REDO LOG do STANDBY? Isso realmente funciona?

Abs
Rodrigo

On 12/15/06, jonathan_brbs <[EMAIL PROTECTED]> wrote:
>
>   Olá Rodrigo,
> Infelizmente isso não é possivel antes da versão 10G,
> Onde através do comando ALTER DATABASE START LOGICAL STANDBY APPLY
> IMMEDIATE conseguimos fazer a aplicação direta de Redos. Para
> standby físico o comando seria ALTER DATABASE RECOVER MANAGED
> STANDBY DATABASE USING CURRENT LOGFILE.
>
> []s
> Jonathan Barbosa
>
> --- Em oracle_br@yahoogrupos.com.br ,
> "Rodrigo Telles"
> <[EMAIL PROTECTED]> escreveu
> >
> > Pessoal,
> > estou montando um ambiente de DATA GUARD aqui na empresa e estou
> usando o
> > LOGICAL STANDBY.
> > Minha duvida é o seguinte:
> > No PRIMARY configurei o log_archive_dest_2='SERVICE=GUARD_146 LGWR
> SYNC
> > AFFIRM' e o PROTECTION_MODE está em MAXIMUM AVAILABILITY.
> > No banco LOGICAL STANDBY eu criei os grupos de STANDBY REDO LOG.
> > Com isso estou querendo testar a situação de nenhum dado perdido
> em caso de
> > falha de comunicação entre os bancos.
> >
> > A teoria do ambiente acima diz que quando faço o COMMIT de uma
> transação no
> > PRYMARY o comando só é retornado quando essa transação for escrita
> nos
> > standby redo logs (garantindo que o outro banco recebeu a
> transação). Porém
> > quando rodo um script que popula uma tabela no PRIMARY e faço o
> commit na
> > transação, NADA acontece no banco STANDBY. Eu só consigo ver as
> inserções no
> > standby se eu der o SWITCH LOG FILE no banco PRIMARY. Nessa hora
> eu consigo
> > ver o LOG APPLY trabalhando e a tabela sendo populada.
> >
> > Como consigo fazer uma transação, quando "comitada" no banco
> principal, seja
> > vista na banco standby sem precisar ficar dando o switch logfile
> ou esperar
> > o proprio banco fazer o switch?
> >
> > Meu banco é o 9.2.0.8.
> >
> > Grato pela ajuda
> >
> > Rodrigo
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
> 
>


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] DATA GUARD - SINCRONISMO - LOGICAL STANDBY

[Rodrigo Telles]

Pessoal,
estou montando um ambiente de DATA GUARD aqui na empresa e estou usando o
LOGICAL STANDBY.
Minha duvida é o seguinte:
No PRIMARY configurei o log_archive_dest_2='SERVICE=GUARD_146 LGWR SYNC
AFFIRM' e o PROTECTION_MODE está em MAXIMUM AVAILABILITY.
No banco LOGICAL STANDBY eu criei os grupos de STANDBY REDO LOG.
Com isso estou querendo testar a situação de nenhum dado perdido em caso de
falha de comunicação entre os bancos.

A teoria do ambiente acima diz que quando faço o COMMIT de uma transação no
PRYMARY o comando só é retornado quando essa transação for escrita nos
standby redo logs (garantindo que o outro banco recebeu a transação). Porém
quando rodo um script que popula uma tabela no PRIMARY e faço o commit na
transação, NADA acontece no banco STANDBY. Eu só consigo ver as inserções no
standby se eu der o SWITCH LOG FILE no banco PRIMARY. Nessa hora eu consigo
ver o LOG APPLY trabalhando e a tabela sendo populada.

Como consigo fazer uma transação, quando "comitada" no banco principal, seja
vista na banco standby sem precisar ficar dando o switch logfile ou esperar
o proprio banco fazer o switch?

Meu banco é o 9.2.0.8.

Grato pela ajuda

Rodrigo


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Index - Monitoring Usage

[Rodrigo Telles]

Pessoal,
temos alguns indices na nossa base que estão desconfiados que não estão
sendo mais usados.
Para monitorar isso quero colocar a monitoração dos índices com a cláusula
MONITORING USAGE (alter index).

Gostaria de saber se algúem já usou essa feature e se ele impacta muito na
performance do banco.


Sds

Rodrigo

Meu ambiente: Solaris 8 / Oracle 9..0.4


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Problemas com estatísticas do banco.

[Rodrigo Telles]

Pessoal
estou com uma dúvida aqui e gostaria de saber se já passaram por isso.
O banco de produção daqui tem um comportamento que para mim é estranho.

É o seguinte: Toda vez que precisamos fazer shutdown para alguma
intervenção a parte da WEB, que tira relatórios no banco, fica totalmente
prejudicada. Telas que levavam segundos para aparecer não aparecem mais.

Na primeira vez que fui fazer um shutdown uma pessoa da equipe me avisou que
após o startup era necessário rodar ANALYZE para as tabelas (essas tabelas
são particionadas!!) dessas respectivas telas. Duvidei muito disso na
primeira vez pois shutdown/startup não mexe em nada com estatisticas de
tabela!!! Mas o pior que isso tem acontecido mesmo. Ontem foi a segunda vez
que precisei fazer shutdown/startup no banco. Para variar, as telas de
relatório pararam de funcionar e logo após o analyze terminar as telas
voltaram ao normal(consultas feitas com a tempo de resposta normal). Alguém
já viu isso antes?

Um DBA me falou que pode estar acontecendo de as estasticias ficarem STALE
após o shutdown/startup.

Alguém poderia me ajudar?

O SO é Solaris 8 e o Banco é o 9.2.0.4.

Abs
Rodrigo


[As partes desta mensagem que não continham texto foram removidas]

Re: [oracle_br] Re: Problemas com estatisticas do Banco

[Rodrigo Telles]

Luis/Chiappa/Marcio
muito obrigado pela atenção e ajuda.
Só mais uma pergunta: Caso o problema seja um bug mesmo e as estatisticas
fiquem STALE. Onde eu posso verificar esse tipo de coisa? Em qual view eu
consigo afirmar que as estatisticas ficaram STALE?

Fazendo uma comparação com os indices, eles ficam UNUSABLE em caso de um
move de tabela. No caso da procedure elas ficam INVALID caso estejam com
erro de compilação e assim por diante. Queria saber onde se pode verificar
que as estatisticas estão STALE.


Sds
Rodrigo




On 11/28/06, Marcio Portes <[EMAIL PROTECTED]> wrote:
>
>   Luis, um gancho na sua idéia seria comparar as estatísticas... Dessa
> forma o
> colega teria certeza que há diferenças nas estatísticas e poderá acionar o
> suporte com o CASE na mão.
>
> On 11/28/06, Luis Fernando Cerri <[EMAIL PROTECTED] >
> wrote:
> >
> > Rodrigo, considere fazer um export das estatísticas deste(s) schema(s)
> > via
> > dbms_stats antes do shutdown. Após o startup, você as importa.
> >
> > Isso definitivamente não é a solução para seu problema, que deve ser
> > atacado
> > como o Chiappa propôs, mas pelo menos você diminuirá consideravelmente o
> > tempo para normalizar as consultas já que não será mais necessário o
> > analyze.
> >
> > []s
> > Luis
> >
> > Em 28/11/06, jlchiappa <[EMAIL 
> > PROTECTED] com.br>>
> > escreveu:
> > >
> > > Colega, eu absolutamente NUNCA vi comportamento do tipo, e meu banco
> > > é 9.2.0.5 e eu faço um shutdown semanal (em HP-ux, porém) : com
> > > absoluta certeza, SE realmente as estatísticas estão MESMO ficando
> > > (erradamente!) marcadas como stale após um shutdown, isso NÃO É
> > > comportamento-padrão, vc tem um bug aí em mãos sem dúvida, é acionar
> > > o Suporte, sem dúvida. Antes, porém, ao invés de tentar "adivinhar",
> > > eu recomendaria que vc, ou o DBA, FIZESSE A AVALIAÇÃO CORRETA E
> > > PRECISA do que está acontecendo, só dizer "ah, relatório pára de
> > > funcionar" é absolutamente INSUFICIENTE O procedimento mínimo
> > > seria : com banco ativo e estats coletadas e ok, PESQUISE as views de
> > > estatísticas (ie, DBA_TABLES, DBA_TAB_COLUMNS, DBA_TAB_HISTOGRAMS,
> > > DBA_INDEXES, DBA_IND_COLUMNS, DBA_HISTOGRAMS, etc, etc) para as
> > > tabelas TODAS envolvidas (inclusive tabelas temporárias, no caso de
> > > particionadas estats TANTO das partições QUANTo estats globais, etc),
> > > rode o report ATIVANDO TRACE 10053 e o 10046, depois fazer shutdown e
> > > repetir o processo, aí vc TEM como comparar e saber as diferenças,
> > > ie , se mudou ou não plano, se mudou ou não estatísticas, o status
> > > delas, se os wiats foram radicalmente diferentes
> > >
> > > []s
> > >
> > > Chiappa
> > >
> > > --- Em oracle_br@yahoogrupos.com.br 
> > >  rupos.com.br> > rupos.com.br>,
> >
> > > "Rodrigo Telles"
> > > <[EMAIL PROTECTED]> escreveu
> > > >
> > > > Pessoal
> > > > estou com uma dúvida aqui e gostaria de saber se já passaram por
> > > isso.
> > > > O banco de produção daqui tem um comportamento que para mim é
> > > estranho.
> > > >
> > > > É o seguinte: Toda vez que precisamos fazer shutdown para alguma
> > > > intervenção a parte da WEB, que tira relatórios no banco, fica
> > > totalmente
> > > > prejudicada. Telas que levavam segundos para aparecer não aparecem
> > > mais.
> > > >
> > > > Na primeira vez que fui fazer um shutdown uma pessoa da equipe me
> > > avisou que
> > > > após o startup era necessário rodar ANALYZE para as tabelas (essas
> > > tabelas
> > > > são particionadas!!) dessas respectivas telas. Duvidei muito disso
> > > na
> > > > primeira vez pois shutdown/startup não mexe em nada com
> > > estatisticas de
> > > > tabela!!! Mas o pior que isso tem acontecido mesmo. Ontem foi a
> > > segunda vez
> > > > que precisei fazer shutdown/startup no banco. Para variar, as telas
> > > de
> > > > relatório pararam de funcionar e logo após o analyze terminar as
> > > telas
> > > > voltaram ao normal(consultas feitas com a tempo de resposta
> > > normal). Alguém
> > > > já viu isso antes?
> > > >
> > > > Um dba me falou que isso pode estar ocorrendo pois as estatisticas
> > > podem
> > > > ficar stale no shutdown/startup. Alguém ja ouviu falar sobre isso?
> > > >
> > > >
> > > > O SO é Solaris 8 e o Banco é o 9.2.0.4.
> > > >
> > > > Abs
> > > >
> > > > Rodrigo
> > > >
> > > >
> > > > [As partes desta mensagem que não continham texto foram removidas]
> > > >
> > >
> > >
> > >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
>
> --
> Marcio Portes
> Material Tecnico em Portugues - http://mportes.blogspot.com
> Practical Learning Oracle -
> http://mportes.blogspot.com/2006/02/practical-learning-oracle.html
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> 
>


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Problemas com estatisticas do Banco

[Rodrigo Telles]

Pessoal
estou com uma dúvida aqui e gostaria de saber se já passaram por isso.
O banco de produção daqui tem um comportamento que para mim é estranho.

É o seguinte: Toda vez que precisamos fazer shutdown para alguma
intervenção a parte da WEB, que tira relatórios no banco, fica totalmente
prejudicada. Telas que levavam segundos para aparecer não aparecem mais.

Na primeira vez que fui fazer um shutdown uma pessoa da equipe me avisou que
após o startup era necessário rodar ANALYZE para as tabelas (essas tabelas
são particionadas!!) dessas respectivas telas. Duvidei muito disso na
primeira vez pois shutdown/startup não mexe em nada com estatisticas de
tabela!!! Mas o pior que isso tem acontecido mesmo. Ontem foi a segunda vez
que precisei fazer shutdown/startup no banco. Para variar, as telas de
relatório pararam de funcionar e logo após o analyze terminar as telas
voltaram ao normal(consultas feitas com a tempo de resposta normal). Alguém
já viu isso antes?

Um dba me falou que isso pode estar ocorrendo pois as estatisticas podem
ficar stale no shutdown/startup. Alguém ja ouviu falar sobre isso?


O SO é Solaris 8 e o Banco é o 9.2.0.4.

Abs

Rodrigo


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Statspack

[Rodrigo Telles]

Pessoal,
estou querendo comprar um livro sobre STATSPACK para 9i.
Gostaria, se possível, que me enviassem o nome de algum livro para eu possa
comprar e estudar.

Andei pesquisando e achei o da Oracle Press mesmo:
*Oracle9i High-Performance Tuning with STATSPACK (Paperback)
*by Donald K. 
Burleson.
Vcs já leram esse? Gostaram? No site da Amazon eu vi alguns cmentários ruins
sobre o livro.

Abs e já agradeço pela ajuda.

Rodrigo


[As partes desta mensagem que não continham texto foram removidas]



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
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

 

[oracle_br] Simulado 1Z0-030 - New Features 9i

[Rodrigo Telles]

Pessoal,
gostaria  de saber se alguém poderia me ajudar a encontrar um SelfTest para
a prova 1Z0-030 - New Features 9i?
Já procurei nos arquivos do grupo e não tem esse simulado.

Se alguém tiver e puder me enviar eu agradeço muito. Pode ser para esse
email mesmo.

Grato
Rodrigo


[As partes desta mensagem que não continham texto foram removidas]







--
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine 
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário.





  




  
Yahoo! Grupos, um serviço oferecido por:
  
  

PUBLICIDADE




  
  



  




  
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 Termos do Serviço do Yahoo!.

Re: [oracle_br] Re: Erro relacionado ao HASH_IO_MULTBLOCK_COUNT

[Rodrigo Telles]

Chiappa,
era isso mesmo que vc falou. Existe uma tablespace HORRIVELMENTE pequena
setada para o usuário owner das tabelas. Setei uma outra temp com initial e
next maiores e deu certo.

Muito obrigado pela ajuda.

Sds

Rodrigo


On 12/30/05, jlchiappa <[EMAIL PROTECTED]> wrote:
>
> Bom, eu nunca vi esse erro nos anos q trabalhei com 8i, mas indo por
> partes :
>
> a) provavelmente esse número "2" deve ser algum número sequencial
> interno das tablespaces, talvez das tabelas nnn$ e
> não "oficializado/suportado" no dicionário, já que não aparece na
> DBA_TABLESPACES
>
> b) a nota 75183.1 (vc não diz, mas deve ser o que vc leu) diz
> diretamente que o erro é de tablespace (ou objeto dentro da
> tablespace) com NEXT (e portanto tamanho de extent) inferior à qtdade
> de blocos múltiplos exigida :
>
> "An attempt was made to specify a HASH_MULTIBLOCK_IO_COUNT value that
>is greater than the tablespace's NEXT value "
>
> c) quando vc tem HASH_MULTIBLOCK_IO_COUNT igual a zero, isso *
> NÂO ** significa que não vai ser usado, MAS sim que o próprio
> banco vai escolher o valor : a nota 125271.1
> Subject:  How to Choose Extent Size for Temporary Tablespace to
> Prevent ORA-3232 diz textualmente isso :
>
> "When HASH_MULTIBLOCK_IO_COUNT it set to 0, it means that Oracle
> computes the value
> for each query. Sometimes ORA-3232 may be encountered when a query
> uses
> HASH JOIN."
>
> ==> juntando tudo, faz sentido : apenas algumas queries o otimizador
> opta por criar tabelas de hash, vc ESTÁ sim usando multiblock pra ler
> quando ocorre hashing, o erro ocorre, COM CERTEZA vc tem alguma
> tablespace (provavelmente a TEMP) ou algum objeto que tem INITIAL ou
> NEXT ou PCTINCREASE ** horrivelmente ** pequenos, ** pessimamente **
> configurados, corrija isso, se vc é o Admin desse banco...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, Rodrigo Telles
> <[EMAIL PROTECTED]> escreveu
> >
> > Pessoal,
> > estou tentando executar uma query porém tenho recebido o seguinte
> erro ORA
> >
> > Error: ORA-3232
> >
> > Text: unable to allocate an extent of 8 blocks from tablespace 2
> >
> > O mais estranho é que a query so retorna esse erro para alguns
> parâmetros de
> > entrada. Em outros casos ela executa normalmente. Eu li no metalink
> que o
> > problema pode estar relacionado ao HASH_IO_MULTBLOCK_COUNT (que no
> meu banco
> > ta setado como zero) e quando ocorre um Hash Join na query. Para
> resolver o
> > problema temporariamente eu forcei o uso de um outro JOIN atraves
> de Hint.
> > Mas queria mesmo saber o pq desse problema e o que significa essa
> tablespace
> > 2. Seria a TEMP? Alguém ja tomou esse erro?
> >
> > Meu banco é um Oracle 8.1.7.4 em um AIX 4.3.3
> >
> > Segue a query:
> >
> > SELECT
> >  T.ID_TELEVENDA,
> >   FROM
> >  TB_TV_TELEVENDA T,
> >  TB_TV_SERVICO S,
> >  TB_TV_TIPO_ACESSO_SEV TA,
> >  TB_TV_FLUXO_TELEVENDA FT
> >  WHERE
> >  T.ID_FLUXO_TELEVENDA = :ID_FLUXO_TELEVENDA   -- Dependendo do dado
> de
> > entrado o erro acontece
> >  AND FT.CD_STATUS NOT IN ('FIM', 'CAN')
> >  AND T.ID_FLUXO_TELEVENDA = FT.ID_FLUXO_TELEVENDA
> >  AND T.ID_SERVICO = S.ID_SERVICO
> >  AND T.ID_TIPO_ACESSO = TA.ID_TIPO_ACESSO(+)
> >
> > Abs
> >
> > Rodrigo
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>
>
>
>
>
>
>
> --
> Atenção! As mensagens deste grupo são de acesso público e de inteira
> responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
>
> --_
> Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423
> Links do Yahoo! Grupos
>
>
>
>
>
>
>
>


[As partes desta mensagem que não continham texto foram removidas]



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--_
Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423  
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

 

[oracle_br] Erro relacionado ao HASH_IO_MULTBLOCK_COUNT

[Rodrigo Telles]

Pessoal,
estou tentando executar uma query porém tenho recebido o seguinte erro ORA

Error: ORA-3232

Text: unable to allocate an extent of 8 blocks from tablespace 2

O mais estranho é que a query so retorna esse erro para alguns parâmetros de
entrada. Em outros casos ela executa normalmente. Eu li no metalink que o
problema pode estar relacionado ao HASH_IO_MULTBLOCK_COUNT (que no meu banco
ta setado como zero) e quando ocorre um Hash Join na query. Para resolver o
problema temporariamente eu forcei o uso de um outro JOIN atraves de Hint.
Mas queria mesmo saber o pq desse problema e o que significa essa tablespace
2. Seria a TEMP? Alguém ja tomou esse erro?

Meu banco é um Oracle 8.1.7.4 em um AIX 4.3.3

Segue a query:

SELECT
 T.ID_TELEVENDA,
  FROM
 TB_TV_TELEVENDA T,
 TB_TV_SERVICO S,
 TB_TV_TIPO_ACESSO_SEV TA,
 TB_TV_FLUXO_TELEVENDA FT
 WHERE
 T.ID_FLUXO_TELEVENDA = :ID_FLUXO_TELEVENDA   -- Dependendo do dado de
entrado o erro acontece
 AND FT.CD_STATUS NOT IN ('FIM', 'CAN')
 AND T.ID_FLUXO_TELEVENDA = FT.ID_FLUXO_TELEVENDA
 AND T.ID_SERVICO = S.ID_SERVICO
 AND T.ID_TIPO_ACESSO = TA.ID_TIPO_ACESSO(+)

Abs

Rodrigo


[As partes desta mensagem que não continham texto foram removidas]



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--_
Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423  
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

 

Re: [oracle_br] Export Full e snapshot too old

[Rodrigo Telles]

Ederson/Eduardo
Realmente tenho reparado que o erro não acontece sempre.
Vou tentar mudar de horário o export. Colocar num horario de menor
movimento.
Valeu pela dica de vcs.

Eduardo, eu so não entendi o pq de se colocar CONSISTENT=Y que ai terei o
snapshot too old. Para mim pelo o que entendo disso o export com o
consistent=y ele nunca olhará o segment de rollback, não é? ele so pega
dados realmente comitados. Estou com conceito errado?

Abs


On 12/20/05, Claro, Eduardo <[EMAIL PROTECTED]> wrote:
>
> Se você colocar o CONSISTENT=Y, aí é que vai ter snapshot tôo old mais
> facilmente mesmo. Volte isso para N, ou se quiser realmente que o export
> seja totalmente consistente a um momento do tempo, deixe Y, mas faça o
> export sem ninguém mais conectado, por exemplo após um backup frio e startup
> com RESTRICT.
>
> O snapshot too old está acontecendo em tabelas grandes porque essas
> tabelas foram alteradas durante o export, e o seu segmento de rollback não
> conseguiu comportar os dados antigos pelo tempo necessário para o export da
> tabela inteira. Portanto, para resolver isso duas soluções são possíveis:
>
> 1) efetuar o export em um horário de pouco movimento. A quantidade de
> alterações na tabela será pequena e a chance do erro ocorrer será menor.
>
> 2) aumentar os segmentos de rollback. De preferência, para esse caso,
> deixe apenas um segmento ativo, e grande o suficiente para conter as
> alterações efetuadas durante o export.
>
> Com certeza, combinando as duas soluções você terá um melhor resultado.
>
> []s
>
> Eduardo Claro
>
> -Original Message-
> From: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED]
> On Behalf Of Rodrigo Telles
> Sent: terça-feira, 20 de dezembro de 2005 09:04
> To: oracle_br@yahoogrupos.com.br
> Subject: [oracle_br] Export Full e snapshot too old
>
> Pessoal,
> estou com um problema em um export full em um banco (oracle 8.1.7)  que
> temos aqui.
> Na hora da export das maiores tabelas de alguns esquemas eu tomo o erro de
> snapshot too old. Já li a respeito e até tentei a alternativa de colocar o
> CONSISTENT=y no parfile. Mas não adiantou nada. O erro continua
> acontecendo.
>
> Será que a alternativa de aumentar o segmento de rollback é válida?
>
> Algum de vcs teria alguma sugestão de como resolver o problema?
>
> Abs
>
> Rodrigo
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
>
> --
> Atenção! As mensagens deste grupo são de acesso público e de inteira
> responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
>
> --_
> Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423
> Links do Yahoo! Grupos
>
>
>
>
>
>
>
>
>
>
> --
> Atenção! As mensagens deste grupo são de acesso público e de inteira
> responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
>
> --_
> Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423
> Links do Yahoo! Grupos
>
>
>
>
>
>
>
>
>


[As partes desta mensagem que não continham texto foram removidas]



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--_
Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423  
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

 

[oracle_br] Export Full e snapshot too old

[Rodrigo Telles]

Pessoal,
estou com um problema em um export full em um banco (oracle 8.1.7)  que
temos aqui.
Na hora da export das maiores tabelas de alguns esquemas eu tomo o erro de
snapshot too old. Já li a respeito e até tentei a alternativa de colocar o
CONSISTENT=y no parfile. Mas não adiantou nada. O erro continua acontecendo.

Será que a alternativa de aumentar o segmento de rollback é válida?

Algum de vcs teria alguma sugestão de como resolver o problema?

Abs

Rodrigo


[As partes desta mensagem que não continham texto foram removidas]



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--_
Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423  
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

 

[oracle_br] Migraçao AIX - HACMP - Oracle

[Rodrigo Telles]

Pessoal,
tenho o seuinte ambiente:
AIX 4.3.3 com HACMP 4.4.1 em duas máquinas IBM 7026-6h1
O Oracle é o 8.1.7 com Parallel Server.

Aqui na empresa estão querendo migrar para o AIX 5.2 com o HACMP 5.3.
A minha dúvida é a seguinte: Serei obrigado a migrar o Oracle para 9i
junto com essa migração. Alguem sabe se o Parallel Server-8i é compatível
com o novo ambiente que queremos implementar (AIX 5.2 com o HACMP 5.3)?.
Não queríamos migrar tudo de uma vez. Primeiro gostaríamos de migrar o SO e
HACMP e num outro momento migrar o 8i para 9i.
Gostaria de saber se isso é possível.

Onde posso encontrar esse tipo de informação de
compatibilidade de SO com HACMP e o Oracle?.

Grato

Rodrigo


[As partes desta mensagem que não continham texto foram removidas]



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--_
Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423  
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