É isso aí, EM HAVENDO um backup ao menos minimamente completo, E em vc usando o procedimento correto (inclusive voltando todos os datafiles, sem querer usar datafile de um banco em outro), vai super- tranquilo. O que normalmente me faz reputar como incertos esses trabalhos é que muitas vezes vc NÂO TEM CERTEZA da qualidade do backup, mas em ele estando íntegro e completo é bico de tudo, sim.
[]s Chiappa =========================================================== Participe do ENPO - Encontro de Profissionais Oracle 2006 ! Informações e inscrições em www.enpo-br.org José Laurindo Chiappa, Palestrante ENPO-2006 =========================================================== --- Em oracle_br@yahoogrupos.com.br, rflribeiro <[EMAIL PROTECTED]> escreveu > > Não teve erro, chiappa. > Os cd's de instalação da versão que estava sendo utilizada antes do drop > geral estavam lá e havia uma pasta com os scripts de backup, que > continham os logs das operações. Nos logs das operações, consegui o nome > e a estrutura anterior do banco de dados. O arquivo de senha eu recriei > com o orapwd. Retornei os controls e os datafiles (inclusive o system), > abri com MOUNT e fiz o recover com BACKUP CONTROL FILES UNTIL CANCEL. > Apliquei os archives que tinha (ainda ficaram faltando uns 3). Terminei > o recover com CANCEL, abri o banco com RESETLOGS e vida normal, fazer o > quê? O cliente ficou sem a movimentação das 12:00h (últimos archives > disponíveis) até às 17:00h (archives perdidos). Se não fossem os scripts > de backup p/ me passar a estrutura anterior, ia ficar "na água". > > Obrigado. > > Reginaldo Ribeiro > skype: dbcom_it_experts > Mobile: 551192344290 > > > > jlchiappa wrote: > > Reginaldo, ** DIFICILMENTE ** eu reputo vc trabalhar com algo feito > > por outra pessoa como "bobeira de final de semana", em ESPECIAL > > administração de banco, pois se a pessoa que o fez não tinha uma > > sólida noção de admin, não era um DBA e sim um curioso, quase que > > FATALMENTE vc descobre que a tarefa foi mal-feita, feita pela > > metade.... E é aquela água, o coitado do cliente sempre acha que tudo > > foi feito certinho, muitas vezes mal sabe ele a inhaca que tá no > > banco dele... > > Bom, no caso : pra começo de conevrsa. vc querer, como vc diz que > > fez, criar uma nova instância , criar um NOVO database , copiar o > > datafile dum outro banco (da tablespace SYSTEM no caso, mas fosse > > qual fosse) e querer subir essa instância com enormes chances ** NÃO > > ** vai funcionar : veja vc, como mostrado (por exemplo) em > > http://database.sarang.net/database/oracle/concept/oracle- > > internal/db_block.html , dentro dos blocos de um datafile Oracle > > ficam SIM registradas informações sobre o banco origem, que criou > > esse datafile (tais como OBJECT_ID, SCN do banco, etc) : ORA, se vc > > criou um novo banco, o nome do banco e alguns detalhes até são os > > mesmos, mas MUITO PROVAVELMENTE o SCN é outro, o id é outro, então o > > RDBMS ** não vai mesmo ** aceitar esse datafile como parte do banco, > > já que as infos de banco presentes no datafile estão DIFERENTES das > > do banco!!! Esse "erro informando que o datafile da tablespace system > > não é deste banco de dados" é isso, é o óbvio do óbvio, só por PURA > > SORTE dois bancos vão ter o mesmo SCN, mesmos IDs... > > > > Para que vc possa voltar sem falhas um backup em caso de perda total > > dos datafiles e da instância (o que parece ser o caso aí), as > > exigências MÍNIMAS do bd Oracle são as seguintes : se em modo archive > > (que parece que é o caso, já que vc fala em hot backup), vc TEM QUE > > ter um backup de TODOS os datafiles (** inclusive o SYSTEM!!), tem > > que ter os controlfiles, o initfile/spfile, os archived logs de desde > > o backup, e preferencialmente os log files não-archivados (sem eles, > > vc até voltaria o banco mas só até o instante do último archive). > > Além disso tudo estar no backup, vc tem que OU ter um backup dos > > BINÁRIOS ORACLE (e ajutórios, como Serviços e REGISTRY no caso de > > windows), OU vc tem que saber exatamente QUAL ERA a versão de banco, > > aí vc re-instala os binários a partir do CD, aplica os patches até > > chegar na versão que estava. ==> UMA VEZ os binários estando OK, vc > > deve criar os diretórios/filesystems exatamente como estavam, vc > > volta o backup dos datafiles e , se vc não tiver a instância vc a > > cria (comando ORADIM no windows, no unix é simplesmente setar as vars > > e startup nomount), faz-se o recover normalm do database, e é isso. > > > > ==> Já se o que vc têm em mãos NÃO É um backup full, completo (com > > TODOS os tópicos acima!!) e íntegro, o que vc tem na verdade é lixo > > digital, e aí cfrme a situação talvez se possa ou não recuperar uma > > parte da informação - se é esse o caso , passe outra msg com os > > detalhes TODOS de SO, hardware, versões, o que vc tem e não tem, que > > a gente pode tentar te ajudar mais... > > > > > > []s > > > > Chiappa > Vem aí: ENPO-BR 2006 - Encontro Nacional de Profissionais Oracle VISITE: http://www.enpo-br.org/ - Dia 11/11 "Vagas Limitadas" ________________________________________________________________ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine -------------------------------------------------------------------------------------------------------------------------- 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/ -------------------------------------------------------------------------------------------------------------------------- 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: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
