Seguem minhas anotacoes sobre o uso de dumps de banco que sao utilizados no dia a dia. Para uma orientacao completa e melhor consultar os manuais da Oracle ou o Metalink.Formas de export:Se as maquinas envolvidas tiverem o mesmo sistema operacional e versao do oracle pode usar o direct que e mais rapido se forem diferentes melhor usar o buffer que mais seguro a compatibilidade.Se usar o compress=y, que e o default, quando for importar, vai tentar criar o "initial extent" do tamanho total da tabela na origem. Se nao tiver espaco continuo no banco, nao vai conseguir importar.Exemplo de export:No prompt de comando DOS ou Unix utilizar o comandoexp usuario_banco/xxx@sidbanco direct=y recordlength=65536 feedback=10000 compress=n file=arquivo_bkp.dmp log=arquivo_bkp.log tables=minha_tabela_grande exp usuario_banco/xxx@sidbanco buffer=33554432 GRANTS=n INDEXES=n CONSTRAINTS=n compress=n feedback=10000 file=arquivo_bkp.dmp tables="minha_tabela_grande" Exemplo de import para recuperar o backup:No prompt de comando DOS ou Unix utilizar o comandoimp usuario_banco/xxx@sidbanco buffer=33554432 commit=y feedback=10000 file=arquivo_bkp.dmp tables="minha_tabela_grande" Os projetos de TI envolvem uma diversidade de profissionais de varias areas de atuacao e mesmos nos projetos mais simples sempre existe uma rotatividade de profissionais muito grande devido a demanda de mercado, neste cenario de grandes e constantes mudancas, ter uma boa documentacao para que possa ser registrado para ser utilizado no futuro por outras pessoas e fundamental, fator critico em qualquer projeto de TI. Infelizmente ainda hoje nos deparamos com varios casos onde ela e muito rara, inconsistente, de ma qualidade ou praticamente inexistente, gerando grandes perdas financeiras e dependencia muito forte com os profissionais envolvidos no processo, esta e uma questao muito polemica na area porque esta deficiencia documentacao pode ser causada por varios motivos, os mais frequentes sao incapacidade dos profissionais, falta de incentivo ou valorizacao deste trabalho pelas empresas e tambem proposital quando se quer gerar a dependencia entre cliente e fornecedor, quem trabalha na area com certeza conhece algum fornecedor tecnico que nao pode ser trocado por dominar algum sistema, tudo por uma deficiencia, intencional ou nao, grave de documentacao e processos. Existe no mercado uma infinidade muito grande de padroes de documentacao, os grandes consumidores de TI criam seus padroes para se resguardar de fornecedores inescrupulosos e os fornecedores possuem seus proprios padroes para se resguardar de situacoes inesperadas e perdas financeiras. Geralmente estas documentacoes seguem um padrao de implementacao de projeto, de fabrica de software ou de atendimento outsource onde vamos ter de forma resumida uma documentacao de escopo utilizada para contratacao, a documentacao funcional descrevendo todas as funcionalidades envolvidas que tambem podem ser utilizadas para contratacao, as documentacoes tecnicas utilizadas para o desenvolvimento dos aplicativos e as documentacoes de testes e aceite final das solucoes. Existem varios ciclos de vida de desenvolvimento de sistemas, ultimamente tenho utilizado o padrao da Oracle "AIM for business flow" que e bastante completo, tem documentos de testes de regressao, calculo de esforco de desenvolvimento, alem de utilizar uma abordagem de etapas de implantacao Conference Room Pilots (CRPs) e nao para os requisitos o que resulta em uma abordagem muito mais rapida possibilitando reduzir consideravelmente o tempo de implantacao de projeto. O projeto R12 de implantacao do OEBS