Menu de navegação

[mpvargasParticipante]

Caros amigos,
Após fazer um teste de backup do RMAN em outro servidor, porém usando o mesmo catálogo do meu banco de produção, estou recebendo o seguinte erro na execução do script do RMAN:

connected to recovery catalog database

connect target /
RMAN-06004: ORACLE error from recovery catalog database:
RMAN-20011: target database incarnation is not current in recovery catalog

Pesquisei e descobri que eu devo usar o comando RESET DATABASE, mas estou com receio pois nunca usei esse comando e não sei se o mesmo causará algum problema no meu banco de produção.

[mpvargasParticipante]

Gostaria de saber se é necessário parar a instância para executar o comando RESET DATABASE no RMAN.

[vieriParticipante]

nunca vi esse erro… se eu fosse você, daria um “UNREGISTER DATABASE” e um “REGISTER DATABASE” no catalogo…
pois provavelmente essa base foi resturada com openresetlogs e não está batendo a incarnação com a regitrada no catalog.

[]s.

[mpvargasParticipante]

OK Vieri
Deu certo
Muito Obrigado.

[PetersonParticipante]

putz, foi em cima hein Vieri…

[CleitonHanzenParticipante]

[quote=”mpvargas”:3g7zoxyw]Caros amigos,
Após fazer um teste de backup do RMAN em outro servidor, porém usando o mesmo catálogo do meu banco de produção, estou recebendo o seguinte erro na execução do script do RMAN:

connected to recovery catalog database

connect target /
RMAN-06004: ORACLE error from recovery catalog database:
RMAN-20011: target database incarnation is not current in recovery catalog

Pesquisei e descobri que eu devo usar o comando RESET DATABASE, mas estou com receio pois nunca usei esse comando e não sei se o mesmo causará algum problema no meu banco de produção.[/quote]

Opá..

Bom, o Reset Database somente irá fazer com que o RMAN “busque” as informações do incarnation correto no catálogo.

Já o unregister database EXCLUI todos os registros daquele dbid no cátalogo, isso se torna perigoso, se você tem uma retention policy maior que 7 dias, haja visto que, durante 7 dias os backups executados ainda permenecem no controlfile….

Ainda assim, se você tiver algum export do catálogo anterior ao resetlogs, faça um import do catálog e do banco de produção faça um resync via RMAN, já deve deixar teu catálogo zeradinho…. 😉

[mpvargasParticipante]

Valeu Cleiton,
Estava preocupado com o comando “RESET DATABASE” pois não tinha certeza sobre o impacto que causaria no ambiente de produção…
Obrigado pela explicação com relação aos comandos…
Meu RMAN tem retenção de 2 dias e faço o export todos os dias de madrugada, sendo assim acho que não terei problemas ao excluir os registros do catálogo…
Obrigado pela ajuda

[vieriParticipante]

Perigoso não é, pois vc pode restaurar
um backup antigo registrando o backup, antes do restore.
E será feito normalmente. A Oracle não iria usar o catalogo como
mais um ponto de falha, para restores..

Agora uma pergunta:
O reset apenas atualiza as “credênciais” da instância no catalogo?
ou ele varre todos os backups que ja foram feitos e faz um updates
em todas infos de backup passados? e deixam ele prontos para serem restaurados? Sem restrições de incarnação e sem que ter que setar nada na mão?

Na documentação ele apenas diz que após um resetlogs o reset deve ser usado mas não diz os impactos nem oque ele faz nas tabelas internas do rman, apenas diz que o rman irá voltar parar de dar o erro e permitir ~
as novas operações, isso o unregister e register tb faz.

isso pode ser descoberto via testes… quem se prontifica? rs..

outro detalhe se o open resetlogs for feito pelo RMAN ele automaticamente já faz o reset. No seu caso deve ter sido pelo sqlplus ou sem está conectado no catalogo.

A restrições e informações sobre o reset estão abaixo.

http://download.oracle.com/docs/cd/B137 … ynta50.htm

Oracle® Database Recovery Manager Reference
10g Release 1 (10.1)
Part Number B10770-01

Restrictions and Usage Notes
Execute RESET DATABASE only at the RMAN prompt.
You must be connected to the target database.
A recovery catalog connection is optional. Unlike in catalog mode, RESET DATABASE in nocatalog mode changes the incarnation only for the current RMAN session.
You must issue a RESET DATABASE command before you can use RMAN with a target database that has been opened with the SQL statement ALTER DATABASE OPEN RESETLOGS option. If you do not, then RMAN refuses to access the recovery catalog because it cannot distinguish between a RESETLOGS operation and an accidental restore of an old control file. The RESET DATABASE command informs RMAN that you issued a RESETLOGS command.
If RMAN is connected NOCATALOG, then you can only specify TO INCARNATION if the database is mounted and the control file contains a record of the prior incarnation. If you do not run RESET DATABASE, RMAN recovers to the last incarnation recorded in the control file.
If RMAN is connected in CATALOG mode, then you can specify TO INCARNATION when the database is mounted. If database is mounted, however, then the control file must have a record of the prior incarnation.
Keywords and Parameters

[CleitonHanzenParticipante]

[quote=”vieri”:31be6g0y]
Perigoso não é, pois vc pode restaurar
um backup antigo registrando o backup, antes do restore.
E será feito normalmente. A Oracle não iria usar o catalogo como
mais um ponto de falha, para restores..

[/quote]

E no caso de MML (digamos, TSM) como faz?

E no caso de backup com keep forever usando MML?

Desconheço qualquer forma de restore destes backups sem catálogo ou no mínimo sem ter logs do backup e ter o nome do backup do controlfile gerado….

[]s

[vieriParticipante]

1°)Vc não precisa do catalogo para restaurar um banco.
basta encontrar os backup pieces. Se vc não sabe aonde vc guarda eles muda de emprego ou demita seu gerente de infra. É obvio que lá no catalogo está armazenado bonitinho o seu format em algumas linhas de uma tabela.

2°)backup eterno usando media manager, existem outras maneiras como a própria ferramenta de mml ou uma outra maneira de catalogo para armazenar ou sempre que um cliente te disponibilizar um backup com rman ele lhe darão um DMP do catalogo, ou no máximo os logs?

3°)Se você perder o servidor do catalogo e ele não for feito backup como ocorre nos principais clientes, seu backup keep forever se torna inválido?
toda empresa deve saber oque tem em cada fita e existes softwares para gerenciar isso.

4°) Você pode nomear cada backup piece como quiser, para facil localização.

5°) Voce pode e deve armazenar todos os logs do seus backups.

6°) Melhor com ele, ruim sem ele ele.. ele é um repósitório de informação sobre os backups e não uma ferramenta. ferramenta é o RMAN, com o catalogo vc abre o leque de possibilidades apenas. Mas as funcionalidades principais não são perdidas.

Se eu fosse vc eu vestiria uma camisa e saia nas ruas assim..
“usem o catalogo do rman todos os problemas da sua infra-estrutura estão acabados.” Não é assim que a banda toca..

Cada caso é um caso, cada cenário é um cenário,
existem empresa que o catalogo é fundamental em outras não..

Em empresas vc tem mml em outras não, em empresas vc tem robo,
outras não, em empresas vc armazena a fita on site em outras não,
em empresas as fitas são armazendas em empresas especializadas em reter e documentar as fitas outras não..

Se vc fizer isso tudo que eu disse e ainda ter catalogo ótimo, nota 10.
se vc não tiver catalogo e ter uma infra-estrutura organizada está ótimo também. Pois existem outros banco de dados também que não possuem catalogo e vc deve está pronto para isso. Ou sua empresa é toda Oracle,
desde a portaria até o RH ? vc precisa saber em qual fita está o seu backup do oracle do mssql , do mysql de tudo.

obs: Eu uso catalogo em todas minhas bases produtivas, mas por outros motivos que não incluem o contexto desse post, alêm disso nosso software de MML(symantec backup exec) possui catalogo de todos os backups, oque é cada fita,
oque tem dentro dela, e a data dela. Não tenho nenhum tipo de problema para localizar um backup sendo ele do oracle, com catalogo sem catalogo… e por ai vai…

Quando surgiu o catalogo da Oracle, ja existia catalogo por outras maneiras a oracle inovou muito mas não é a pioneira.

Pra quem é pobrinho e não tem mml , o catalogo é uma mão na roda, mas quem tem que é a grande maioria, ele se torna um recurso a mais
dentro desse contexto aqui desse post.

[CleitonHanzenParticipante]

É por isso que gosto de participar do GPO….quando estou com a mente “fechada” vem um profissional de respeito e mostra como as coisas realmente são (ou melhor, como deveriam ser)….

Eu trabalho com clientes grandes, mas na sua grande maioria utilizam Oracle Standard Edition e tem algumas limitações quanto à profissionalização das áreas de TI, vamos dizer assim…

Vocês que trabalham em grandes centros, são “abençados” por poderem extrair o máximo que as ferramentas tem a oferecer, a maioria aqui em S.C. tira leite de pedra mesmo….tudo bem xing-ling e pior de tudo, não adianta querer mudar a visão dos gestores de TI…pra eles quem investe no ambiente, está “perdendo tempo”….

Fazer o que né? A vida continua e nós se fu…rsrsrsrsrs

Abraços e obrigado pelos esclarecimentos Vieri… 😉

[vieriParticipante]

Beleza Cleiton, 😉

eu já fui consultor ja coloquei a mão na massa e sei como são as empresas que trabalham ao modo bacalhau, eu simplesmente não uso elas como fonte de informação,
simplemente coloca pra funcionar e segue vida.

E também sei como são gestores de pouca visão e intransigentes,
estes deviam ser gestores de outra área e não de TI.

Gostei dos seus posts e do debate, é assim que se assimila informação.
eu aprendi sobro o reset database e vc ampliou a sua visão para ambientes maiores. E o pessoal que ler tb vai assimilar algo tb!

Uma dúvida sobre reset database gerou um debate sobre localização de fitas com backup em keep forever usando mml. rsrs
no minímo fantástico. O estado da arte para Crash Recovery. 😆

Feliz ano novo, sucesso paz. Backups em dia e restores funcionando!!
E upgrade de salário para nós DBA que estudamos pra &%$#@#$¨!!!
viva os DBA’s Oracle do Brasil!! E os DBA’s de outra tecnologia também,
pois como diz o Portilho, DBA que sabe vários bancos ganha mais!!

Mas todos nós sabemos que Oracle é e sempre será o melhor por pelo menos 20anos.

Abraços a todos e até ano que vem…. Diversão e o descanso.

[Autor]

Posts