Re: [oracle_br] Re: Performance em Query - Evento de Espera - PX Deq: Execute Reply
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 oracle_br%40yahoogrupos.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
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
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
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
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 oracle_br%40yahoogrupos.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
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
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 estatisticas do Banco
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]
Re: [oracle_br] Re: Problemas com estatisticas do Banco
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] lfcerri%40gmail.com 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]jlchiappa%40yahoo.com.brjlchiappa%40yahoo. 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 oracle_br%40yahoogrupos.com.broracle_br%40yahoog rupos.com.broracle_br%40yahoog 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 estatísticas do banco.
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]
[oracle_br] Simulado 1Z0-030 - New Features 9i
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
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] 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 * 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
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] Migraçao AIX - HACMP - Oracle
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
