[oracle_br] WAIT...
GeleiraBom dia. Estou tendo uns casos de wait na minha instância. Está ocorrendo latch: cache buffers chains e db file, como faço para resolver esses problemas, identifiquei e não sei qual ação tomar, se eu não matar a sessão dele ele fica horas nesse estado. Grato, Márcio. [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Oracle mais lento que o SQLServer?
Bom dia pessoal, tenho uma aplicação que irá rodar em vários bancos, para testar qual banco esta com melhor performance na nossa aplicação, inserimos 300 mil registros em uma tabela, e tanto no C# quanto no Delphi o Oracle me demora de 2 a 3 segundos a mais que o SQLServer, os testes foram feitos sem alterar nenhum configuração de nenhum dos dois bancos, o Oracle XE 10 G e o SQLServer 2005, sendo que já testamos também no SQLServer2000, não entendo o porque o Oracle sempre tem uma melhora maior... O Oracle XE possui alguma configuração básica que possamos fazer para que melhore esta performance? Agradeço desde já a atenção Tânia
[oracle_br] Extraindo DDLs - DDL Wizard ou qualquer outro..
Bom dia pessoal, Iniciei minhas atividades de geração de DDLS para migrar meu banco 10G EE para um 10G SE e infelizmente, só posos faze-lo via DMP. Por este motivo, preciso gerar todas as DDLS do meu banco origem (tabelas, indices, packages, tablespaces e etc.) e executar tais comandos para criar toda a estrutura antes de migrar os dados... Comecei utilizando o proprio PL/SQL DEVELOPER mas infelizmente ele nao cria DDLS espeficicas tipo, somente indices ou somente tabelas...ele cria tudo junto e preciso abrir no bloco de notas e ficar separando a criação das tabelas, da criação dos indices da criação das constraints... E pelo DDL WIZARD (que nunca utilizei), pelo que entendi, ele só el arquivo sgerados pelo EXP / IMP e não arquivos gerados pelo DATAPUMp... Algum colega teria ideia de uma outra forma mais light de se fazer isso ?
[oracle_br] Re: Oracle mais lento que o SQLServer?
Veja vc, todo banco tem as suas exigências, devido à seus mecanismos de lock e gerenciamento/execução de SQ e quetais : no caso do Oracle para performance decente entre outras se exige ESTATÍSTICAS NAS TABELAS, o USO DE BIND VARIABLES (crítico em caso de SQLs repetitivos, o que deve ser o seu caso), que o programa faça PARSE (compilação, digamos assim) apenas na primeira execução (estas duas últimas são ligadas, normalmente, mas o PARSE pode ser por causa de SQL dinâmico, o que é outro DRENO de CPU), exige-se que se usar drivers tipo ODBC *** DESLIGUE *** a opção de fazer COMMIT a cada instrução (isso é morte na performance via de regra, de lei no bd Oracle só se faz COMMIT ao final da transação, entre outras. A suposição inicial, PORTANTO, é que é a sua aplicação que está desrespeitando um ou mais pré-reqs, sugiro que vc faça o seguinte teste : vá no servidor e conecte no banco VIA SQLPLUS (que aí com 100% de certeza está usando a API default do banco), escreva e execute uma procedure PL/SQL que faça os INSERTs que vc quer (** SEM ** usar SQL dinâmico!!!) e dê commit no final, EM o tempo de execução ser substancialmente menor para inserir as mesmas linhas fica comprovado que é algo na aplicação, que tem que ser analisado e corrigido - neste caso se vc mandar um código-fonte simples que conecte e faça DMLs tal como a aplicação faz, e dizer ** DETALHADAMENTE ** versões de SO, middleware/drivers usados e detalhes do ambiente/hardware quem programe num ambiente parecido pode palpitar (por exemplo, há bugs CONHECIDOS em determinadas versões de odbc/jdbc, pode ser o caso, quem sabe) INCLUSIVE, para uma aplicação que vai rodar em vários bancos é FORTEMENTE RECOMENDADO que vc tenha Procedures que façam a manipulação dos dados, aí a TELA da aplicação não muda nunca, e internamente a aplicação sempre chama os mesmos nomes de procedures, aí a única coisa é que vc teria uma versão das procedures rigorosamente ajeitada pra SQL Server, uma pra DB2, uma pra Oracle, é isso... Já se a performance mesmo via PL/SQL for realmente inferior aí sim a gente pode pensar em mexer nos parâmetros de banco, mas realmente comece pela aplicação... E uma última obs, qual a razão de vc fazer o teste com XE, é isso que o teu cliente vai usar ??? Eu ** DUVIDO ** , pois o XE é EXTREMAMENTE PODADO, ele NÂO usa mais de uma CPU mesmo em máquina multi-core/multi-cpu, NÃO usa mais de 1 Gb de RAM, tem limites de tamanho. Por causa desses limites todos é em muitos casos INVIÁVEL uma aplicação full em Produção nele, pra vc fazer os seus testes a Oracle DISPONIBILIZA TOTALMENTE DE GRAÇA a versão Enterprise do banco dela (o que faz mais sentido de comparar, já que o SQL 2005 a que vc se refere deve ser uma versão FULL também...), vc a baixa em http://technet.oracle.com : repito, essa versão é free PARA TESTES, com dados NÂO-REAIS do cliente, que deve ser o seu caso, imagino... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Tânia tanias...@... escreveu Bom dia pessoal, tenho uma aplicação que irá rodar em vários bancos, para testar qual banco esta com melhor performance na nossa aplicação, inserimos 300 mil registros em uma tabela, e tanto no C# quanto no Delphi o Oracle me demora de 2 a 3 segundos a mais que o SQLServer, os testes foram feitos sem alterar nenhum configuração de nenhum dos dois bancos, o Oracle XE 10 G e o SQLServer 2005, sendo que já testamos também no SQLServer2000, não entendo o porque o Oracle sempre tem uma melhora maior... O Oracle XE possui alguma configuração básica que possamos fazer para que melhore esta performance? Agradeço desde já a atenção Tânia
Re: [oracle_br] Oracle mais lento que o SQLServer?
Tania bom dia, São varios fatores que incluenciam na questão de escrita do Oracle, tais como parametros de memoria, parametros para performance de escrita, uso de FOR? bullk collect? 1) quanto tem de memoria essa maquina que está o Oracle? é a mesma do Sql Server? 2) como está os parametros db_cache*, sga_target*, db_writer* Veja materia sobre bullk collect para vc uma noção do mesmo: http://mportes.blogspot.com/2007/03/bulk-collect_12.html abcs. - Original Message - From: Tânia To: oracle_br@yahoogrupos.com.br Sent: Monday, October 05, 2009 11:06 AM Subject: [oracle_br] Oracle mais lento que o SQLServer? Bom dia pessoal, tenho uma aplicação que irá rodar em vários bancos, para testar qual banco esta com melhor performance na nossa aplicação, inserimos 300 mil registros em uma tabela, e tanto no C# quanto no Delphi o Oracle me demora de 2 a 3 segundos a mais que o SQLServer, os testes foram feitos sem alterar nenhum configuração de nenhum dos dois bancos, o Oracle XE 10 G e o SQLServer 2005, sendo que já testamos também no SQLServer2000, não entendo o porque o Oracle sempre tem uma melhora maior... O Oracle XE possui alguma configuração básica que possamos fazer para que melhore esta performance? Agradeço desde já a atenção Tânia -- O Banco de Dados de Vírus interno expirou. Verificado por AVG - http://www.avgbrasil.com.br Versão: 8.0.233 / Banco de dados de vírus: 270.10.16/1926 - Data de Lançamento: 30/1/2009 17:31 [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Extraindo DDLs - DDL Wizard ou qualquer outro..
Já tentou usar o TOAD? Atenciosamente, Marcos Fontana 2009/10/5 candiurudba candiuru...@yahoo.com.br Bom dia pessoal, Iniciei minhas atividades de geração de DDLS para migrar meu banco 10G EE para um 10G SE e infelizmente, só posos faze-lo via DMP. Por este motivo, preciso gerar todas as DDLS do meu banco origem (tabelas, indices, packages, tablespaces e etc.) e executar tais comandos para criar toda a estrutura antes de migrar os dados... Comecei utilizando o proprio PL/SQL DEVELOPER mas infelizmente ele nao cria DDLS espeficicas tipo, somente indices ou somente tabelas...ele cria tudo junto e preciso abrir no bloco de notas e ficar separando a criação das tabelas, da criação dos indices da criação das constraints... E pelo DDL WIZARD (que nunca utilizei), pelo que entendi, ele só el arquivo sgerados pelo EXP / IMP e não arquivos gerados pelo DATAPUMp... Algum colega teria ideia de uma outra forma mais light de se fazer isso ? [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Extraindo DDLs - DDL Wizard ou qualquer outro..
Meu amigo candiru : primeira coisa, na minha última msg sobre o assunto, eu levantei a hipótese de fazer um TRANSPORT TABLESPACE do EE para o SE, e citei uma documentação que em princípio PERMITIA isso , vc TESTOU isso, antes de deduzir que só dá via exp/imp ??? Sim ?? Em realmente sendo algum tipo de dump de dados que vc vai precisar, EXATAMENTE POR QUE vc precisar alterar/editar os scripts gerados, a idéia não é recriar a estrutura de dados do banco EE origem no MESMO HARDWARE EXATO que hoje tem o SE, que seria removido após os dumps, sendo então o nome das tablespaces, dos datafiles, de tudo enfim mantido EXATAMENTE O MESMO ??? OU, mesmo se for outra máquina, há algum impedimento em se manter nomes e paths idênticos ??? Em sendo possível é ultra-simples, vc faz um dump SEM DADOS, e NÂO PEGANDO índices e constraints (usando ROWS=N INDEXES=N CONSTRAINTS=N STATISTOCS=NONE no exp tradicional, ou as opções pra isso no dp, que existem também) , depois gera o DDL dos índices e constraints (pode ser com a DBMS_METADATA, entre outras), altera-os para incluir NOVALIDATE, NOLOGGING e PARALLEL (com um bom editor de texto que permita trocas com expressões regulares em múltiplos arquivos, tipo Textpad ou Ultraedit, ou mesmo via utils unix de linha de comando não é nada extremamente difícil) , e depois é o tradicional, ie : gera-se vários dumpfiles em paralelo, depois os importamos em paralelo também, e no final aplica-se os DDLs de índices e de constraints.. O FATO porém é que, se vc está procurando por uma GUI aonde vc clicka e já faz tudo, SORRY, não vai achar mesmo Isso é FATO, não sei se é 'light' ou não, mas essa é a maneira... Quanto ao DDL Wizard, sim : ele trabalha com .DMPs gerados pelo exp tradicional, a função dele é extrair pra disco (em vários arquivinhos de texto) os DDLs todos, a vantagem dele é que vc vai ter um arquivo tipo INDEXES.SQL com o DDL dos índices todos, outro CONSTRAINTS.SQL com as constraints, em estando separadinhos é mais fácil se fazer eventuais manipulações, MAS em princípio a manipulação é via editor de texto ou utils de linha de comando Sei que ele tem algmas opções de transformação (tipo, pedir pra gerar os arquivos eliminado ou trocando a cláusula de tablespaces, por exemplo) mas não lembro se ele tem a opção de na hora de gerar os arqs trocar só nos índices e constraints o LOGGING por NOLOGGING, indicar uma PARALLEL clause, o NOVALIDATE, se tiver mais fácil ainda... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, candiurudba candiuru...@... escreveu Bom dia pessoal, Iniciei minhas atividades de geração de DDLS para migrar meu banco 10G EE para um 10G SE e infelizmente, só posos faze-lo via DMP. Por este motivo, preciso gerar todas as DDLS do meu banco origem (tabelas, indices, packages, tablespaces e etc.) e executar tais comandos para criar toda a estrutura antes de migrar os dados... Comecei utilizando o proprio PL/SQL DEVELOPER mas infelizmente ele nao cria DDLS espeficicas tipo, somente indices ou somente tabelas...ele cria tudo junto e preciso abrir no bloco de notas e ficar separando a criação das tabelas, da criação dos indices da criação das constraints... E pelo DDL WIZARD (que nunca utilizei), pelo que entendi, ele só el arquivo sgerados pelo EXP / IMP e não arquivos gerados pelo DATAPUMp... Algum colega teria ideia de uma outra forma mais light de se fazer isso ?
Re: [oracle_br] WAIT...
Pesquisando no Metalink, achei essa nota que diz ter um bug: Bug 3797171 cache buffers chains latch contention increased in 10g Subject: Bug 3797171 - cache buffers chains latch contention increased in 10g Doc ID: 3797171.8 Type: PATCH Modified Date : 24-SEP-2008 Estou enfrentando esse problema, por exemplo, agora tinha uma sessão há 2h e 30 minutos conectados e só esperando. É o meu primeiro acesso no Metalink, alguém pode dar uma dica com esse problema? ORACLE 10.2.0.1.0 HP-UX 11.23 - Original Message - From: Márcio Ricardo Alves da Silva To: oracle_br@yahoogrupos.com.br ; gpora...@yahoogrupos.com.br Sent: Monday, October 05, 2009 9:01 AM Subject: [oracle_br] WAIT... GeleiraBom dia. Estou tendo uns casos de wait na minha instância. Está ocorrendo latch: cache buffers chains e db file, como faço para resolver esses problemas, identifiquei e não sei qual ação tomar, se eu não matar a sessão dele ele fica horas nesse estado. Grato, Márcio. [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: Extraindo DDLs - DDL Wizard ou qualquer outro..
Fala ae Chiappa... Seguinte... Este é o probleminha...estou migrando para um novo servidor (uma lamina Blade) onde todos os paths estarão diferentes do que o original. No servidor que ainda esta em produção, ele não segue nenhuma recomendação da OFA e gostaria de alterar isso...por isso irei recriei toda estrutura neste novo servidor... Quanto a questão do TRANSPORT TABLESPACE...pelo que verifiquei na documentação, eu precisaria copiar os meus .dbf para o outro servidor e na ultima vez que tentei fazer isso (mover 160 GB), demorei cerca de 6 horas e nem tinha chegado ainda na metade da copia...ou seja, se tornou inviável... Outros fatotes desfavoraveis: - Segundo documentação os SO precisariam ser iguais...e neste caso não são...estou utilizando SUSE X RED HAT.. - E objetos de replicação não seriam incluidos neste proesso. Tudo bem que poderiams ser recriados mas... Por estes motivos, pensei em fazer via tradiconal .DMP mesmo mas precisaria alterar todos os paths...no servidor atual, tudo esta concentado em //ORADATA (datafiles, indices, redo multiplexados, controlfile multiplex..) e agora, seguindo a recomendação OFA, indices em uma unidade chamada /u03, dados em uma outra chamada /u02 e assim por diante... --- Em oracle_br@yahoogrupos.com.br, jlchiappa jlchia...@... escreveu Meu amigo candiru : primeira coisa, na minha última msg sobre o assunto, eu levantei a hipótese de fazer um TRANSPORT TABLESPACE do EE para o SE, e citei uma documentação que em princípio PERMITIA isso , vc TESTOU isso, antes de deduzir que só dá via exp/imp ??? Sim ?? Em realmente sendo algum tipo de dump de dados que vc vai precisar, EXATAMENTE POR QUE vc precisar alterar/editar os scripts gerados, a idéia não é recriar a estrutura de dados do banco EE origem no MESMO HARDWARE EXATO que hoje tem o SE, que seria removido após os dumps, sendo então o nome das tablespaces, dos datafiles, de tudo enfim mantido EXATAMENTE O MESMO ??? OU, mesmo se for outra máquina, há algum impedimento em se manter nomes e paths idênticos ??? Em sendo possível é ultra-simples, vc faz um dump SEM DADOS, e NÂO PEGANDO índices e constraints (usando ROWS=N INDEXES=N CONSTRAINTS=N STATISTOCS=NONE no exp tradicional, ou as opções pra isso no dp, que existem também) , depois gera o DDL dos índices e constraints (pode ser com a DBMS_METADATA, entre outras), altera-os para incluir NOVALIDATE, NOLOGGING e PARALLEL (com um bom editor de texto que permita trocas com expressões regulares em múltiplos arquivos, tipo Textpad ou Ultraedit, ou mesmo via utils unix de linha de comando não é nada extremamente difícil) , e depois é o tradicional, ie : gera-se vários dumpfiles em paralelo, depois os importamos em paralelo também, e no final aplica-se os DDLs de índices e de constraints.. O FATO porém é que, se vc está procurando por uma GUI aonde vc clicka e já faz tudo, SORRY, não vai achar mesmo Isso é FATO, não sei se é 'light' ou não, mas essa é a maneira... Quanto ao DDL Wizard, sim : ele trabalha com .DMPs gerados pelo exp tradicional, a função dele é extrair pra disco (em vários arquivinhos de texto) os DDLs todos, a vantagem dele é que vc vai ter um arquivo tipo INDEXES.SQL com o DDL dos índices todos, outro CONSTRAINTS.SQL com as constraints, em estando separadinhos é mais fácil se fazer eventuais manipulações, MAS em princípio a manipulação é via editor de texto ou utils de linha de comando Sei que ele tem algmas opções de transformação (tipo, pedir pra gerar os arquivos eliminado ou trocando a cláusula de tablespaces, por exemplo) mas não lembro se ele tem a opção de na hora de gerar os arqs trocar só nos índices e constraints o LOGGING por NOLOGGING, indicar uma PARALLEL clause, o NOVALIDATE, se tiver mais fácil ainda... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, candiurudba candiurudba@ escreveu Bom dia pessoal, Iniciei minhas atividades de geração de DDLS para migrar meu banco 10G EE para um 10G SE e infelizmente, só posos faze-lo via DMP. Por este motivo, preciso gerar todas as DDLS do meu banco origem (tabelas, indices, packages, tablespaces e etc.) e executar tais comandos para criar toda a estrutura antes de migrar os dados... Comecei utilizando o proprio PL/SQL DEVELOPER mas infelizmente ele nao cria DDLS espeficicas tipo, somente indices ou somente tabelas...ele cria tudo junto e preciso abrir no bloco de notas e ficar separando a criação das tabelas, da criação dos indices da criação das constraints... E pelo DDL WIZARD (que nunca utilizei), pelo que entendi, ele só el arquivo sgerados pelo EXP / IMP e não arquivos gerados pelo DATAPUMp... Algum colega teria ideia de uma outra forma mais light de se fazer isso ?
Re: [oracle_br] Tablespace no 11g
Boa tarde pessoal! Primeiramente obrigado a todos que me responderam, mas o que desejo saber, é se não existe uma funcionalidade tipo a que existe no enterprise manager que me mostre o mapa de tablespace, que permite criar tablespece, adcionar datafile etc. Abs Erickscorrea --- Em sex, 2/10/09, Marcelo Procksch marceloprock...@gmail.com escreveu: De: Marcelo Procksch marceloprock...@gmail.com Assunto: Re: [oracle_br] Tablespace no 11g Para: oracle_br@yahoogrupos.com.br Data: Sexta-feira, 2 de Outubro de 2009, 17:33 Da uma olhada na documentação, tem alguns exemplos http://download. oracle.com/ docs/cd/B28359_ 01/server. 111/b28286/ statements_ 7003.htm# sthref7574 -- Att. Marcelo E. Procksch cel. (11) 7960-6637 2009/10/2 Erick Correa erickscorrea@ yahoo.com. br Boa tarde pessoal ! Desejo saber como faço para criar uma tablespace no Oracle 11g utilizando o SQL developer Alguem pode ma ajudar ? Abs Erickscorrea _ _ _ _ _ _ Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbusca dos.yahoo. com [As partes desta mensagem que não continham texto foram removidas] -- Att. Marcelo E. Procksch cel. (11) 7960-6637 [As partes desta mensagem que não continham texto foram removidas] 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] Como migrar
Boa Tarde srs colegas da lista, Pergunto :Algum colega da lista poderia me auxiliar no seguinte terefa ? Como se migra as tabelas de uma tablespace smallfile para uma tablespace bigfile. SO : Linux DB : Oracle 10g [] Barba [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Como migrar
Boa tarde, O normal... EXP/IMP ou EXPDP/IMPDP ou CTAS (create table as select) ou Alter table move tablespace YY; Atenciosamente, Rodrigo Mufalani OCP 10g 11g OCE RAC 10g R2 Oralce ACE Member mufal...@oi.com.br http://mufalani.blogspot.com Mensagem Original: Data: 14:20:02 05/10/2009 De: Jose - Oracle jap_ora...@yahoo.com.br Assunto: [oracle_br] Como migrar Boa Tarde srs colegas da lista, Pergunto :Algum colega da lista poderia me auxiliar no seguinte terefa ? Como se migra as tabelas de uma tablespace smallfile para uma tablespace bigfile. SO : Linux DB : Oracle 10g [] Barba [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/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 Quer deixar seu Oi com a sua cara? No Mundo Oi você baixa toques, vídeos, jogos, músicas completas e encontra serviços incríveis pro seu Oi e pra internet. Acesse http://www.mundooi.oi.com.br e descubra!
[oracle_br] Re: Extraindo DDLs - DDL Wizard ou qualquer outro..
Segue : estou migrando para um novo servidor (uma lamina Blade) onde todos os paths estarão diferentes do que o original. a idéia do transport era mais adequada se vc quisesse manter a mesma máquina, aí os arquivos em si não mudariam, só os metadados apontando pros paths seriam transferidos do origem pro destino ..na ultima vez que tentei fazer isso (mover 160 GB), demorei cerca de 6 horas e nem tinha chegado ainda na metade da copia...ou seja, se tornou inviável... colega, 160 Gb ** não ** é hoje em dia um volume ultra-absurdo de jeito nenhum... Isso caberia num disco fast SCSI transportável , vc não tem um aí, ou possibilidade de adquirir um, se o seu servidor tiver uma porta rápida (SATA-2 externa ou Firewire ?? Diacho, até uma porta USB-2 ligada numa gaveta de disco com um disco de 7200 rpm ou acima penso que deveria dar conta de transportar menos de 200 Gb em poucas horas. Ou ainda, não tem como o seu pessoal de rede te montar uma rede PRIVADA ***, full Gigabit, entre os dois servidores ? Porque performance tão ralé do tipo de mais de 6h pra nem 200 Gb não me parece boa, parece indicar que vc estava na rede pública comum, CONCORRENDO com o resto das pessoas, não é isso ? - Segundo documentação os SO precisariam ser iguais...e neste caso não são...estou utilizando SUSE X RED HAT.. Sim, há uma razão específica pra vc além de mudar de versão (que já é uma pauleira, já pode dar incompatibilidade) mudar também de SO ? Se houver sim, aí a idéia de transport fica em geladeira - eu não disse proibida pois na prática, se ambas as distros forem de kernel muito próximo, mesmo bitsize, e hardware origem/destino semelhantes ao máximo, até deve funcionar transport entre distros diferentes - recomendo, testa aí com uma ou duas tablespaces escolhidas, em funcionando veja com o teu pessoal de hardware o que eles podem fazer pra melhorar o tempo de cópia, se adquirir um disco externo rápido, se montar uma rede privada direta entre as máquinas, o que der... - E objetos de replicação não seriam incluidos neste proesso. Tudo bem que poderiams ser recriados mas... sim, mas são poucos imagino, deve dar pra fazer manualmente... Por estes motivos, pensei em fazer via tradiconal .DMP mesmo mas precisaria alterar todos os paths...no servidor atual, tudo esta concentado em //ORADATA (datafiles, indices, redo multiplexados, controlfile multiplex..) e agora, seguindo a recomendação OFA, indices em uma unidade chamada /u03, dados em uma outra chamada /u02 e assim por diante... se REALMENTE vc quer/precisa mudar os mountpoints/paths vai dar mais trabalho, mas é possível : ** SE ** vc conseguiu um modo de copiar os arqs rapidamente pro destino e o transport funcionou entre as distros diferentes, vc poderia num primeiro momento ter os datafiles no mesmo path original, depois via ALTER DATABASE RENAME 'pathedatafile' TO 'novopathedatafile' simplesmente os RENOMEAR para o novo path, mudar de fs/path/mount-point no mesmo disco/volume/servidor via de regra é bem rápido... Já se vc não puder fazer o TS e dumps forem a alternativa, se eu fosse vc faria mesmo o dump via exp e extrairia os scripts de DDL com o DDL Wizard, creio que é o mais ´'fácil' a fazer... Sei que o pump tem opções para na hora da importação vc especificar que a tablespace nnnorigem deve ser 'renomeada' para nnnDESTINO, fazendo o objeto a ser importado ir pra tablespace nnndestino independente de como estava no bd origem, mas não usei muito, conslte as docs e veja se vc consegue os resultados desejados []s Chiappa
[oracle_br] Re: Extraindo DDLs - DDL Wizard ou qualquer outro..
Ah, e detalhe importante : só pra dar uma noção do que eu falei sobre tempos de transferência (que pega não só na questão de transport, MAS também para transferir os .DMPs de uma máquina pra outra se chegar a isso), veja http://www.macseven.com/files/20070503_external_hard_drive_transfer_speeds.html , é uma comparação com resultados mais próximos ao que se espera : no pior dos piores casos, que é o USB-2, levou pouco menos de 300 segundos pra transferir 3.83 Gb, ou seja, levaria coisa de pouco menos de 15k segundos , ie, 4h e pouco, pra transferir os 190 Gb que falamos - ok, garantido, flutuações ocorrem, mas quando vc fala que em 6 horas ainda não tinha avançado grande coisa só se pode concluir que a tua performance aí está fedorenta... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, jlchiappa jlchia...@... escreveu Segue : estou migrando para um novo servidor (uma lamina Blade) onde todos os paths estarão diferentes do que o original. a idéia do transport era mais adequada se vc quisesse manter a mesma máquina, aí os arquivos em si não mudariam, só os metadados apontando pros paths seriam transferidos do origem pro destino ..na ultima vez que tentei fazer isso (mover 160 GB), demorei cerca de 6 horas e nem tinha chegado ainda na metade da copia...ou seja, se tornou inviável... colega, 160 Gb ** não ** é hoje em dia um volume ultra-absurdo de jeito nenhum... Isso caberia num disco fast SCSI transportável , vc não tem um aí, ou possibilidade de adquirir um, se o seu servidor tiver uma porta rápida (SATA-2 externa ou Firewire ?? Diacho, até uma porta USB-2 ligada numa gaveta de disco com um disco de 7200 rpm ou acima penso que deveria dar conta de transportar menos de 200 Gb em poucas horas. Ou ainda, não tem como o seu pessoal de rede te montar uma rede PRIVADA ***, full Gigabit, entre os dois servidores ? Porque performance tão ralé do tipo de mais de 6h pra nem 200 Gb não me parece boa, parece indicar que vc estava na rede pública comum, CONCORRENDO com o resto das pessoas, não é isso ? - Segundo documentação os SO precisariam ser iguais...e neste caso não são...estou utilizando SUSE X RED HAT.. Sim, há uma razão específica pra vc além de mudar de versão (que já é uma pauleira, já pode dar incompatibilidade) mudar também de SO ? Se houver sim, aí a idéia de transport fica em geladeira - eu não disse proibida pois na prática, se ambas as distros forem de kernel muito próximo, mesmo bitsize, e hardware origem/destino semelhantes ao máximo, até deve funcionar transport entre distros diferentes - recomendo, testa aí com uma ou duas tablespaces escolhidas, em funcionando veja com o teu pessoal de hardware o que eles podem fazer pra melhorar o tempo de cópia, se adquirir um disco externo rápido, se montar uma rede privada direta entre as máquinas, o que der... - E objetos de replicação não seriam incluidos neste proesso. Tudo bem que poderiams ser recriados mas... sim, mas são poucos imagino, deve dar pra fazer manualmente... Por estes motivos, pensei em fazer via tradiconal .DMP mesmo mas precisaria alterar todos os paths...no servidor atual, tudo esta concentado em //ORADATA (datafiles, indices, redo multiplexados, controlfile multiplex..) e agora, seguindo a recomendação OFA, indices em uma unidade chamada /u03, dados em uma outra chamada /u02 e assim por diante... se REALMENTE vc quer/precisa mudar os mountpoints/paths vai dar mais trabalho, mas é possível : ** SE ** vc conseguiu um modo de copiar os arqs rapidamente pro destino e o transport funcionou entre as distros diferentes, vc poderia num primeiro momento ter os datafiles no mesmo path original, depois via ALTER DATABASE RENAME 'pathedatafile' TO 'novopathedatafile' simplesmente os RENOMEAR para o novo path, mudar de fs/path/mount-point no mesmo disco/volume/servidor via de regra é bem rápido... Já se vc não puder fazer o TS e dumps forem a alternativa, se eu fosse vc faria mesmo o dump via exp e extrairia os scripts de DDL com o DDL Wizard, creio que é o mais ´'fácil' a fazer... Sei que o pump tem opções para na hora da importação vc especificar que a tablespace nnnorigem deve ser 'renomeada' para nnnDESTINO, fazendo o objeto a ser importado ir pra tablespace nnndestino independente de como estava no bd origem, mas não usei muito, conslte as docs e veja se vc consegue os resultados desejados []s Chiappa
[oracle_br] Pesquisa de Conteúdo
Boa tarde. Preciso fazer uma pesquisa em todas as Procedures, Triggers, Packages, Functions, etc, por todos os momentos em que um comando update é realizado em uma determinada coluna de uma tabela. Alguém saberia uma forma rápida e eficiente de se realizar essa busca sem que seja Escovando BIT ?? Att. -- Evandro Giachetto Oracle Certified Associate evan...@clickinterativa.com.br [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Pesquisa de Conteúdo
Você pode utilizar a view dba_source. Select * from dba_source where upper(text) like '%PARÂMETRO DE PESQUISA %' Adilson Prates Rodrigues Administrador de Banco de Dados Coordenação-Geral de Tecnologia e Informação Fundo Nacional de Desenvolvimento da Educação – FNDE Setor Bancário Sul, Quadra 2, Bloco F - Edifício FNDE Cep: 70.070-929 - Brasília – DF Telefone: (61) 2022 4530 Site: http://www.fnde.gov.br E-mail: adilson.rodrig...@fnde.gov.br Mensagem original De: Evandro Giachetto evandrogiache...@gmail.com Reply-to: oracle_br@yahoogrupos.com.br Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Pesquisa de Conteúdo Data: Mon, 5 Oct 2009 15:49:35 -0300 Boa tarde. Preciso fazer uma pesquisa em todas as Procedures, Triggers, Packages, Functions, etc, por todos os momentos em que um comando update é realizado em uma determinada coluna de uma tabela. Alguém saberia uma forma rápida e eficiente de se realizar essa busca sem que seja Escovando BIT ?? Att. -- Evandro Giachetto Oracle Certified Associate evan...@clickinterativa.com.br [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: Pesquisa de Conteúdo
E ainda, se o SQL em questão não é dinâmico, consultando a DBA_DEPENDENCIES vc obtém a lista dos objetos que 'mexem' com a tabela em questão, não sendo muito longa vc vai na DBA_SOURCE ** apenas ** para os poucos caras que mexem na tabela x []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Adilson Prates adilson.rodrig...@... escreveu Você pode utilizar a view dba_source. Select * from dba_source where upper(text) like '%PARÂMETRO DE PESQUISA %' Adilson Prates Rodrigues Administrador de Banco de Dados Coordenação-Geral de Tecnologia e Informação Fundo Nacional de Desenvolvimento da Educação â FNDE Setor Bancário Sul, Quadra 2, Bloco F - Edifício FNDE Cep: 70.070-929 - Brasília â DF Telefone: (61) 2022 4530 Site: http://www.fnde.gov.br E-mail: adilson.rodrig...@... Mensagem original De: Evandro Giachetto evandrogiache...@... Reply-to: oracle_br@yahoogrupos.com.br Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Pesquisa de Conteúdo Data: Mon, 5 Oct 2009 15:49:35 -0300 Boa tarde. Preciso fazer uma pesquisa em todas as Procedures, Triggers, Packages, Functions, etc, por todos os momentos em que um comando update é realizado em uma determinada coluna de uma tabela. Alguém saberia uma forma rápida e eficiente de se realizar essa busca sem que seja Escovando BIT ?? Att. -- Evandro Giachetto Oracle Certified Associate evan...@... [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Pesquisa de Conteúdo
Muito obrigado. Em 05/10/09, Adilson Prates adilson.rodrig...@fnde.gov.br escreveu: Você pode utilizar a view dba_source. Select * from dba_source where upper(text) like '%PARÂMETRO DE PESQUISA %' Adilson Prates Rodrigues Administrador de Banco de Dados Coordenação-Geral de Tecnologia e Informação Fundo Nacional de Desenvolvimento da Educação FNDE Setor Bancário Sul, Quadra 2, Bloco F - Edifício FNDE Cep: 70.070-929 - Brasília DF Telefone: (61) 2022 4530 Site: http://www.fnde.gov.br E-mail: adilson.rodrig...@fnde.gov.br adilson.rodrigues%40fnde.gov.br Mensagem original De: Evandro Giachetto evandrogiache...@gmail.comevandrogiachetto%40gmail.com Reply-to: oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br Para: oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br Assunto: [oracle_br] Pesquisa de Conteúdo Data: Mon, 5 Oct 2009 15:49:35 -0300 Boa tarde. Preciso fazer uma pesquisa em todas as Procedures, Triggers, Packages, Functions, etc, por todos os momentos em que um comando update é realizado em uma determinada coluna de uma tabela. Alguém saberia uma forma rápida e eficiente de se realizar essa busca sem que seja Escovando BIT ?? Att. -- Evandro Giachetto Oracle Certified Associate evan...@clickinterativa.com.br evandro%40clickinterativa.com.br [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] -- Evandro Giachetto Oracle Certified Associate evan...@clickinterativa.com.br [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/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 * 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: oracle_br-unsubscr...@yahoogrupos.com.br * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
[oracle_br] Re: Extraindo DDLs - DDL Wizard ou qualquer outro..
Eu ja tratei com o pessoal de infra para dar uma olhadinha nisso...ja sugeri inclusive ligarmos la um cabo cross e fazermos esta copia... Mas chiappa, surgiu uma dúvida... Com relação ao Transport Tablespace...preciso criar o dump e fazer a importação para o novo banco + a copia dos dbf para o novo servidor...logo, a copia precisa ser fria para a consistencia ne...ou seja...algum tempo do banco fora do ar...ou posso dar um off line nas tablespaces que serão copiadas, fazendo a copia via SO e deixar o banco no ar ??!! --- Em oracle_br@yahoogrupos.com.br, jlchiappa jlchia...@... escreveu Ah, e detalhe importante : só pra dar uma noção do que eu falei sobre tempos de transferência (que pega não só na questão de transport, MAS também para transferir os .DMPs de uma máquina pra outra se chegar a isso), veja http://www.macseven.com/files/20070503_external_hard_drive_transfer_speeds.html , é uma comparação com resultados mais próximos ao que se espera : no pior dos piores casos, que é o USB-2, levou pouco menos de 300 segundos pra transferir 3.83 Gb, ou seja, levaria coisa de pouco menos de 15k segundos , ie, 4h e pouco, pra transferir os 190 Gb que falamos - ok, garantido, flutuações ocorrem, mas quando vc fala que em 6 horas ainda não tinha avançado grande coisa só se pode concluir que a tua performance aí está fedorenta... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, jlchiappa jlchiappa@ escreveu Segue : estou migrando para um novo servidor (uma lamina Blade) onde todos os paths estarão diferentes do que o original. a idéia do transport era mais adequada se vc quisesse manter a mesma máquina, aí os arquivos em si não mudariam, só os metadados apontando pros paths seriam transferidos do origem pro destino ..na ultima vez que tentei fazer isso (mover 160 GB), demorei cerca de 6 horas e nem tinha chegado ainda na metade da copia...ou seja, se tornou inviável... colega, 160 Gb ** não ** é hoje em dia um volume ultra-absurdo de jeito nenhum... Isso caberia num disco fast SCSI transportável , vc não tem um aí, ou possibilidade de adquirir um, se o seu servidor tiver uma porta rápida (SATA-2 externa ou Firewire ?? Diacho, até uma porta USB-2 ligada numa gaveta de disco com um disco de 7200 rpm ou acima penso que deveria dar conta de transportar menos de 200 Gb em poucas horas. Ou ainda, não tem como o seu pessoal de rede te montar uma rede PRIVADA ***, full Gigabit, entre os dois servidores ? Porque performance tão ralé do tipo de mais de 6h pra nem 200 Gb não me parece boa, parece indicar que vc estava na rede pública comum, CONCORRENDO com o resto das pessoas, não é isso ? - Segundo documentação os SO precisariam ser iguais...e neste caso não são...estou utilizando SUSE X RED HAT.. Sim, há uma razão específica pra vc além de mudar de versão (que já é uma pauleira, já pode dar incompatibilidade) mudar também de SO ? Se houver sim, aí a idéia de transport fica em geladeira - eu não disse proibida pois na prática, se ambas as distros forem de kernel muito próximo, mesmo bitsize, e hardware origem/destino semelhantes ao máximo, até deve funcionar transport entre distros diferentes - recomendo, testa aí com uma ou duas tablespaces escolhidas, em funcionando veja com o teu pessoal de hardware o que eles podem fazer pra melhorar o tempo de cópia, se adquirir um disco externo rápido, se montar uma rede privada direta entre as máquinas, o que der... - E objetos de replicação não seriam incluidos neste proesso. Tudo bem que poderiams ser recriados mas... sim, mas são poucos imagino, deve dar pra fazer manualmente... Por estes motivos, pensei em fazer via tradiconal .DMP mesmo mas precisaria alterar todos os paths...no servidor atual, tudo esta concentado em //ORADATA (datafiles, indices, redo multiplexados, controlfile multiplex..) e agora, seguindo a recomendação OFA, indices em uma unidade chamada /u03, dados em uma outra chamada /u02 e assim por diante... se REALMENTE vc quer/precisa mudar os mountpoints/paths vai dar mais trabalho, mas é possível : ** SE ** vc conseguiu um modo de copiar os arqs rapidamente pro destino e o transport funcionou entre as distros diferentes, vc poderia num primeiro momento ter os datafiles no mesmo path original, depois via ALTER DATABASE RENAME 'pathedatafile' TO 'novopathedatafile' simplesmente os RENOMEAR para o novo path, mudar de fs/path/mount-point no mesmo disco/volume/servidor via de regra é bem rápido... Já se vc não puder fazer o TS e dumps forem a alternativa, se eu fosse vc faria mesmo o dump via exp e extrairia os scripts de DDL com o DDL Wizard, creio que é o mais ´'fácil' a fazer... Sei que o pump tem opções para na hora da importação vc especificar que a tablespace nnnorigem deve ser 'renomeada'
[oracle_br] Re: Extraindo DDLs - DDL Wizard ou qualquer outro..
Mas chiappa, surgiu uma dúvida... vamos lá ... Com relação ao Transport Tablespace...preciso criar o dump e fazer a importação para o novo banco + a copia dos dbf para o novo servidor... é, e não esquecendo que esse dump não é de dados, mas sim METADADOS, ie, só INSERTs nas tabelas internas do bd Oracle informando-o sobre a nova tablespace... logo, a copia precisa ser fria para a consistencia ne...ou seja...algum tempo do banco fora do ar...ou posso dar um off line nas tablespaces que serão copiadas, fazendo a copia via SO e deixar o banco no ar ??!! na verdade não só pode como DEVE deixar o banco online MAS com as tablespaces em questão indisponíveis (read-only, se é só leitura já basta pra ele saber que não terá mudanças nos metadados) : afinal, se vc baixar o banco, Obviamente o exp.exe ** não ** vai ter acesso às tabelas internas para buscar o metadado que deve ser copiado... []s Chiappa OBS : again de novo, em msgs anteriores eu Avisei sobre as várias restrições do tablespace Transport, tais como a necessidade de que os objetos estejam auto-contidos na mesma tablepace, http://www.oracle-base.com/articles/9i/TransportableTablespaces9i.php dá uma mostrada na API que a Oracle disponibiliza para vc ver se a tablespace que vc quer é Transportável ou não... --- Em oracle_br@yahoogrupos.com.br, jlchiappa jlchiappa@ escreveu Ah, e detalhe importante : só pra dar uma noção do que eu falei sobre tempos de transferência (que pega não só na questão de transport, MAS também para transferir os .DMPs de uma máquina pra outra se chegar a isso), veja http://www.macseven.com/files/20070503_external_hard_drive_transfer_speeds.html , é uma comparação com resultados mais próximos ao que se espera : no pior dos piores casos, que é o USB-2, levou pouco menos de 300 segundos pra transferir 3.83 Gb, ou seja, levaria coisa de pouco menos de 15k segundos , ie, 4h e pouco, pra transferir os 190 Gb que falamos - ok, garantido, flutuações ocorrem, mas quando vc fala que em 6 horas ainda não tinha avançado grande coisa só se pode concluir que a tua performance aí está fedorenta... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, jlchiappa jlchiappa@ escreveu Segue : estou migrando para um novo servidor (uma lamina Blade) onde todos os paths estarão diferentes do que o original. a idéia do transport era mais adequada se vc quisesse manter a mesma máquina, aí os arquivos em si não mudariam, só os metadados apontando pros paths seriam transferidos do origem pro destino ..na ultima vez que tentei fazer isso (mover 160 GB), demorei cerca de 6 horas e nem tinha chegado ainda na metade da copia...ou seja, se tornou inviável... colega, 160 Gb ** não ** é hoje em dia um volume ultra-absurdo de jeito nenhum... Isso caberia num disco fast SCSI transportável , vc não tem um aí, ou possibilidade de adquirir um, se o seu servidor tiver uma porta rápida (SATA-2 externa ou Firewire ?? Diacho, até uma porta USB-2 ligada numa gaveta de disco com um disco de 7200 rpm ou acima penso que deveria dar conta de transportar menos de 200 Gb em poucas horas. Ou ainda, não tem como o seu pessoal de rede te montar uma rede PRIVADA ***, full Gigabit, entre os dois servidores ? Porque performance tão ralé do tipo de mais de 6h pra nem 200 Gb não me parece boa, parece indicar que vc estava na rede pública comum, CONCORRENDO com o resto das pessoas, não é isso ? - Segundo documentação os SO precisariam ser iguais...e neste caso não são...estou utilizando SUSE X RED HAT.. Sim, há uma razão específica pra vc além de mudar de versão (que já é uma pauleira, já pode dar incompatibilidade) mudar também de SO ? Se houver sim, aí a idéia de transport fica em geladeira - eu não disse proibida pois na prática, se ambas as distros forem de kernel muito próximo, mesmo bitsize, e hardware origem/destino semelhantes ao máximo, até deve funcionar transport entre distros diferentes - recomendo, testa aí com uma ou duas tablespaces escolhidas, em funcionando veja com o teu pessoal de hardware o que eles podem fazer pra melhorar o tempo de cópia, se adquirir um disco externo rápido, se montar uma rede privada direta entre as máquinas, o que der... - E objetos de replicação não seriam incluidos neste proesso. Tudo bem que poderiams ser recriados mas... sim, mas são poucos imagino, deve dar pra fazer manualmente... Por estes motivos, pensei em fazer via tradiconal .DMP mesmo mas precisaria alterar todos os paths...no servidor atual, tudo esta concentado em //ORADATA (datafiles, indices, redo multiplexados, controlfile multiplex..) e agora, seguindo a recomendação OFA, indices em uma unidade chamada /u03, dados em uma outra chamada /u02 e assim por
[oracle_br] Re: Extraindo DDLs - DDL Wizard ou qualquer outro..
Voce também poderia utilizar o RMAN a partir de um backupset para gerar o Transport Tablespace (O que não comprometeria a disponibilidade do banco de produção). Isso também ajudaria, se for o seu caso, a contornar o erro ORA-29308. Abraços Alessandro Guimaraes --- Em oracle_br@yahoogrupos.com.br, jlchiappa jlchia...@... escreveu Mas chiappa, surgiu uma dúvida... vamos lá ... Com relação ao Transport Tablespace...preciso criar o dump e fazer a importação para o novo banco + a copia dos dbf para o novo servidor... é, e não esquecendo que esse dump não é de dados, mas sim METADADOS, ie, só INSERTs nas tabelas internas do bd Oracle informando-o sobre a nova tablespace... logo, a copia precisa ser fria para a consistencia ne...ou seja...algum tempo do banco fora do ar...ou posso dar um off line nas tablespaces que serão copiadas, fazendo a copia via SO e deixar o banco no ar ??!! na verdade não só pode como DEVE deixar o banco online MAS com as tablespaces em questão indisponíveis (read-only, se é só leitura já basta pra ele saber que não terá mudanças nos metadados) : afinal, se vc baixar o banco, Obviamente o exp.exe ** não ** vai ter acesso às tabelas internas para buscar o metadado que deve ser copiado... []s Chiappa OBS : again de novo, em msgs anteriores eu Avisei sobre as várias restrições do tablespace Transport, tais como a necessidade de que os objetos estejam auto-contidos na mesma tablepace, http://www.oracle-base.com/articles/9i/TransportableTablespaces9i.php dá uma mostrada na API que a Oracle disponibiliza para vc ver se a tablespace que vc quer é Transportável ou não... --- Em oracle_br@yahoogrupos.com.br, jlchiappa jlchiappa@ escreveu Ah, e detalhe importante : só pra dar uma noção do que eu falei sobre tempos de transferência (que pega não só na questão de transport, MAS também para transferir os .DMPs de uma máquina pra outra se chegar a isso), veja http://www.macseven.com/files/20070503_external_hard_drive_transfer_speeds.html , é uma comparação com resultados mais próximos ao que se espera : no pior dos piores casos, que é o USB-2, levou pouco menos de 300 segundos pra transferir 3.83 Gb, ou seja, levaria coisa de pouco menos de 15k segundos , ie, 4h e pouco, pra transferir os 190 Gb que falamos - ok, garantido, flutuações ocorrem, mas quando vc fala que em 6 horas ainda não tinha avançado grande coisa só se pode concluir que a tua performance aí está fedorenta... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, jlchiappa jlchiappa@ escreveu Segue : estou migrando para um novo servidor (uma lamina Blade) onde todos os paths estarão diferentes do que o original. a idéia do transport era mais adequada se vc quisesse manter a mesma máquina, aí os arquivos em si não mudariam, só os metadados apontando pros paths seriam transferidos do origem pro destino ..na ultima vez que tentei fazer isso (mover 160 GB), demorei cerca de 6 horas e nem tinha chegado ainda na metade da copia...ou seja, se tornou inviável... colega, 160 Gb ** não ** é hoje em dia um volume ultra-absurdo de jeito nenhum... Isso caberia num disco fast SCSI transportável , vc não tem um aí, ou possibilidade de adquirir um, se o seu servidor tiver uma porta rápida (SATA-2 externa ou Firewire ?? Diacho, até uma porta USB-2 ligada numa gaveta de disco com um disco de 7200 rpm ou acima penso que deveria dar conta de transportar menos de 200 Gb em poucas horas. Ou ainda, não tem como o seu pessoal de rede te montar uma rede PRIVADA ***, full Gigabit, entre os dois servidores ? Porque performance tão ralé do tipo de mais de 6h pra nem 200 Gb não me parece boa, parece indicar que vc estava na rede pública comum, CONCORRENDO com o resto das pessoas, não é isso ? - Segundo documentação os SO precisariam ser iguais...e neste caso não são...estou utilizando SUSE X RED HAT.. Sim, há uma razão específica pra vc além de mudar de versão (que já é uma pauleira, já pode dar incompatibilidade) mudar também de SO ? Se houver sim, aí a idéia de transport fica em geladeira - eu não disse proibida pois na prática, se ambas as distros forem de kernel muito próximo, mesmo bitsize, e hardware origem/destino semelhantes ao máximo, até deve funcionar transport entre distros diferentes - recomendo, testa aí com uma ou duas tablespaces escolhidas, em funcionando veja com o teu pessoal de hardware o que eles podem fazer pra melhorar o tempo de cópia, se adquirir um disco externo rápido, se montar uma rede privada direta entre as máquinas, o que der... - E objetos de replicação não seriam incluidos neste proesso. Tudo bem que poderiams ser recriados mas... sim,
