Menu de navegação

[jspaulonciParticipante]

Bom dia pessoal, estou querendo fazer a simulação de voltar uma tablespace com o restante da base disponível, alguem tem um step by step para isso ?

obrigado
João Paulo Spaulonci

[David SiqueiraParticipante]

João tudo beleza?

Você tá querendo fazer um POint-Time-Recover?
Se for esse o caso na apresentação sobre RMAN do Rodrigo eu acredito que vea ter algo sobre, ou até mesmo no Blog dele.

Caso não encontre lá no site SS64 tem umas dicas de como fazelo.

Abraço.

[jspaulonciParticipante]

Sim , entrei no blod do Rodrigo mas não encontrei o assuanto,
pra eu conseguir realizar o restore de um tablespace eu preciso fazer o backup do tablespace pelo RMAN ou o BACKUP FULL DATABASE também resolve ?

obrigado
spaulonci

[David SiqueiraParticipante]

De acordo com o que tem no manual do RMAN se você dropou sua Tablespace ela foi desmarcada do seu controlfile, perdendo assim seus ponteiros com o BD, para tal tarefa você seria obrigado a montar uma base auxiliar com o Rman recuperala, e depois restaura-la na base de dados original de onde você a perdeu.

Caso vocÊ não tenha dropado , acredito que seja apenas um recover a ser feito, pois os ponteiros ainda existem ele só precisa ler os arquivos que determinaram a direção do recovery.

Abraço

[David SiqueiraParticipante]

Mais ou menos assim João :

Automatic Instance Creation for RMAN TSPITR
If a tablespace point-in-time recovery (TSPITR) is initiated with no reference to an auxillary instance RMAN now automatically creates an one. The auxillary instance configuration is based on that of the target database. As a result, any channels required for the restore operations must be present in the target database so they are configured correctly in the auxillary instance. The location of the datafiles for the auxillary instance are specified using the AUXILIARY DESTINATION clause shown below.

RECOVER TABLESPACE users
UNTIL LOGSEQ 2400 THREAD 1
AUXILIARY DESTINATION ‘/u01/oradata/auxdest’;The tablespace is taken offline, restored from a backup, recovered to the specified point-in-time in the auxillary instance and re-imported into the target database. The tablespace in the target database should then be backed up and the tablespace brought back online.

BACKUP TABLESPACE users;
SQL “ALTER TABLESPACE users ONLINE”;On successful completion the auxillary instance will be cleaned up automatically. In the event of errors the auxillary instance is left intact to aid troubleshooting.

Link:

http://www.oracle-base.com/articles/10g/RMANEnhancements10g.php

Abraço!!

[jspaulonciParticipante]

Estou pensando em dropar os datafiles da tablespace no ASM, e ver o que acontece, depois disso tentar fazer o restore do meu backup de RMAN

O que vc acha ?

spaulonci

[David SiqueiraParticipante]

Hahaha…
Se não for em produção manda bala..kkkkk

Pelo visto ta no pique de testar as capacidades do RMAN não é?

Vai por mim a ferramenta é surpreendente…

Abração

[jspaulonciParticipante]

kkkk vira essa boca pra lá….é um pequeno ambiente de teste.

[Marcos BragaParticipante]

Oi João Paulo,

Vai uma pequena experiência de restore e recover com um banco de produção (ativo).

Estava eu fazendo sei lá o que da minha vida, mas lembro que era algo com manutenção de espaço; alocando datafiles para partições com espaço disponível para não estourar a produção.

Bom…, em uma dessas alocações, madrugada longa, efetuei um “cp” para cima de um datafile existente e confirmei; deu a maior merda. Resumo da história: perdi o datafile. Que bom que não era um datafile muito utilizado, mas o tranqueira tinha uns 20G (bigfile tablespace).

Sabia que tinha um backup do RMAN de umas 2h; fiz antes de iniciar o procedimento (sei lá Deus o que ocorreria, então sou meio paranóico nesse sentido. rssssss).

Claro que nessa altura estava mais que acordado, nem café fazia mais efeito. rsssss

Primeiro me acalmei e efetuei um restore do datafile (como era o datafile de uma tablespace bigfile, efetuei o procedimento na própria tablespace).

Observe os procedimentos.

1. Deixando a tablespace offline:

RMAN> sql 'alter tablespace MYTABLESPACE offline';

1. Restaurando o datafile (bigfile, efetuei o procedimento na tablespace):

RMAN> restore tablespace MYTABLESPACE;

1. Recuperando os dados (atualizando…):

RMAN> recover tablespace MYTABLESPACE;

1. Voltando a tablespace online:

RMAN> sql 'alter tablespace MYTABLESPACE online';

Felizmente o RMAN é surpreendente mesmo…, demorou um pouco (mais ou menos 30 minutos) para efetuar todo o procedimento (momentos de tensão), mas ao final restaurou o datafile, atualizou os dados e tudo voltou a funcionar normalmente.

Uma pequena experiência que renderam muitos pontos no meu crescimento profissional.

Espero que te ajude.

[]s
Braga

[David SiqueiraParticipante]

Sensacional Braga..rss..e viva a sua Paranóia..hahaha..

Abraço!

[jspaulonciParticipante]

Boa Braga parabens , ainda não passei por isso, apesar que eu trabalhei com um grande adm de SO e ele dissse que sempre devemos utilizar cp e nunca mv, acredito que a esperiência foi realmente válida, ainda bem que vc não infartou e colocou o banco no ar.

Abraços e via a sua paranóia, também sou assim extremamente cuidadoso.

[vieriParticipante]

Passei por esse problema de perder datafile com a base on-line! Mas foi proposital!! 😆

Acho que é exatamente este how to que vai ter que fazer.

Tenho feito varias simulações de crash/recovery… com RMAN.
É extremamente eficaz e eficiente!!!!

Recuperação com RMAN, após remoção “crash” de datafile com a base on-line.

[oracle@admbidev wis]$ rm -rf users.dbf

[oracle@admbidev wis]$ sqlplus / as sysdba ;

SQL*Plus: Release 10.2.0.3.0 – Production on Mon Jul 27 09:28:00 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – Production

With the Partitioning, OLAP and Data Mining options

SQL> shutdown immediate ;

ORA-01116: error in opening database file 35

ORA-01110: data file 35: ‘/u03/wis/users.dbf’

ORA-27041: unable to open file

Linux Error: 2: No such file or directory

Additional information: 3

SQL> shutdown abort ;

ORACLE instance shut down.

SQL> exit

Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – Production

With the Partitioning, OLAP and Data Mining options

[oracle@admbidev wis]$ rman target /

Recovery Manager: Release 10.2.0.3.0 – Production on Mon Jul 27 09:28:23 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database (not started)

RMAN> startup mount ;

Oracle instance started

database mounted

Total System Global Area 536870912 bytes

Fixed Size 1262788 bytes

Variable Size 155192124 bytes

Database Buffers 373293056 bytes

Redo Buffers 7122944 bytes

RMAN> list backup ;

List of Backup Sets

===================

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

1 Full 6.05M DISK 00:00:00 21-JUL-09

    BP Key: 1   Status: AVAILABLE  Compressed: NO  Tag: TAG20090721T153433

    Piece Name: /u03/wis/full_wis_692811273_2

Control File Included: Ckp SCN: 5256320567 Ckp time: 21-JUL-09

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

2 Full 50.58G DISK 00:00:00 21-JUL-09

    BP Key: 2   Status: AVAILABLE  Compressed: NO  Tag: TAG20090721T163226

    Piece Name: /u03/wis/full_wis_692814747_3

List of Datafiles in backup set 2

File LV Type Ckp SCN Ckp Time Name

---

1 Full 5256322985 21-JUL-09 /u03/wis/system01.dbf

2 Full 5256322985 21-JUL-09 /u03/wis/undotbs1.dbf

3 Full 5256322985 21-JUL-09 /u03/wis/sysauy01.dbf

4 Full 5256322985 21-JUL-09 /u03/wis/data_entrega.dbf

5 Full 5256322985 21-JUL-09 /u03/wis/data_entrega_small.dbf

6 Full 5256322985 21-JUL-09 /u03/wis/gkoscf_dtau.dbf

7 Full 5256322985 21-JUL-09 /u03/wis/gkoscf_inau.dbf

8 Full 5256322985 21-JUL-09 /u03/wis/gkoscf_indy.dbf

9 Full 5256322985 21-JUL-09 /u03/wis/indy_entrega.dbf

10 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_asstec.dbf

11 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_cestqhist_32m.dbf

12 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_detprep_32m.dbf

13 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_hist_256k.dbf

14 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_hist_32m.dbf

15 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_hist_5m.dbf

16 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_hist_64m.dbf

17 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_inet.dbf

18 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_sge.dbf

19 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_trcmovestq_64m.dbf

20 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_wis_256k.dbf

21 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_wis_32m.dbf

22 Full 5256322985 21-JUL-09 /u03/wis/tbs_data_wis_5m.dbf

23 Full 5256322985 21-JUL-09 /u03/wis/tbs_indy_asstec.dbf

24 Full 5256322985 21-JUL-09 /u03/wis/tbs_indy_cestqhist_32m.dbf

25 Full 5256322985 21-JUL-09 /u03/wis/tbs_indy_detprep__32m.dbf

26 Full 5256322985 21-JUL-09 /u03/wis/tbs_indy_hist_256k.dbf

27 Full 5256322985 21-JUL-09 /u03/wis/tbs_indy_inet.dbf

28 Full 5256322985 21-JUL-09 /u03/wis/tbs_indy_sge.dbf

29 Full 5256322985 21-JUL-09 /u03/wis/tbs_indy_trcmovestq_64m.dbf

30 Full 5256322985 21-JUL-09 /u03/wis/tbs_indy_wis_256k.dbf

31 Full 5256322985 21-JUL-09 /u03/wis/tbs_indy_wis_32m.dbf

32 Full 5256322985 21-JUL-09 /u03/wis/tbs_indy_wis_5m.dbf

33 Full 5256322985 21-JUL-09 /u03/wis/tools.dbf

34 Full 5256322985 21-JUL-09 /u03/wis/undotbs2.dbf

35 Full 5256322985 21-JUL-09 /u03/wis/users.dbf

36 Full 5256322985 21-JUL-09 /u03/wis/gkoscf_data.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3 Full 6.05M DISK 00:00:00 21-JUL-09

    BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20090721T163226

    Piece Name: /u03/wis/full_wis_692824194_4

Control File Included: Ckp SCN: 5256327637 Ckp time: 21-JUL-09

BS Key Size Device Type Elapsed Time Completion Time

---

4 368.53M DISK 00:00:00 23-JUL-09

    BP Key: 6   Status: AVAILABLE  Compressed: NO  Tag: BKP_WIS_FULL_ARCHIVE

    Piece Name: /u03/wis/arch1_692988571.rman

List of Archived Logs in backup set 4

Thrd Seq Low SCN Low Time Next SCN Next Time

---

1 1184 5256216977 18-JUL-09 5256333244 21-JUL-09

1 1185 5256333244 21-JUL-09 5256367481 22-JUL-09

1 1186 5256367481 22-JUL-09 5256424192 23-JUL-09

1 1187 5256424192 23-JUL-09 5669379585 23-JUL-09

1 1188 5669379585 23-JUL-09 5669379591 23-JUL-09

BS Key Size Device Type Elapsed Time Completion Time

---

5 55.83M DISK 00:00:00 24-JUL-09

    BP Key: 7   Status: AVAILABLE  Compressed: NO  Tag: BKP_WIS_FULL_ARCHIVE

    Piece Name: /u03/wis/arch1_693056610_0ckkud32_1_1.rman

List of Archived Logs in backup set 5

Thrd Seq Low SCN Low Time Next SCN Next Time

---

1 1189 5669379591 23-JUL-09 5669418823 24-JUL-09

1 1190 5669418823 24-JUL-09 5669418831 24-JUL-09

RMAN> restore tablespace users ;

Starting restore at 27-JUL-09

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=157 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00035 to /u03/wis/users.dbf

channel ORA_DISK_1: reading from backup piece /u03/wis/full_wis_692814747_3

channel ORA_DISK_1: restored backup piece 1

piece handle=/u03/wis/full_wis_692814747_3 tag=TAG20090721T163226

channel ORA_DISK_1: restore complete, elapsed time: 00:05:26

Finished restore at 27-JUL-09

RMAN> recover tablespace users ;

Starting recover at 27-JUL-09

using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 1184 is already on disk as file /u03/wis/arch_1_1184_675348192.log

archive log thread 1 sequence 1185 is already on disk as file /u03/wis/arch_1_1185_675348192.log

archive log thread 1 sequence 1186 is already on disk as file /u03/wis/arch_1_1186_675348192.log

archive log thread 1 sequence 1187 is already on disk as file /u03/wis/arch_1_1187_675348192.log

archive log thread 1 sequence 1188 is already on disk as file /u03/wis/arch_1_1188_675348192.log

archive log thread 1 sequence 1189 is already on disk as file /u03/wis/arch_1_1189_675348192.log

archive log thread 1 sequence 1190 is already on disk as file /u03/wis/arch_1_1190_675348192.log

archive log thread 1 sequence 1 is already on disk as file /u03/wis/arch_1_1_693067879.log

archive log filename=/u03/wis/arch_1_1184_675348192.log thread=1 sequence=1184

archive log filename=/u03/wis/arch_1_1185_675348192.log thread=1 sequence=1185

archive log filename=/u03/wis/arch_1_1186_675348192.log thread=1 sequence=1186

archive log filename=/u03/wis/arch_1_1187_675348192.log thread=1 sequence=1187

archive log filename=/u03/wis/arch_1_1188_675348192.log thread=1 sequence=1188

archive log filename=/u03/wis/arch_1_1189_675348192.log thread=1 sequence=1189

archive log filename=/u03/wis/arch_1_1190_675348192.log thread=1 sequence=1190

archive log filename=/u03/wis/arch_1_1191_675348192.log thread=1 sequence=1191

archive log filename=/u03/wis/arch_1_1192_675348192.log thread=1 sequence=1192

archive log filename=/u03/wis/arch_1_1193_675348192.log thread=1 sequence=1193

archive log filename=/u03/wis/arch_1_1194_675348192.log thread=1 sequence=1194

media recovery complete, elapsed time: 00:00:08

Finished recover at 27-JUL-09

RMAN> alter database open ;

database opened

[Rodrigo AlmeidaParticipante]

Mando muito bem Braga!

Essa paranóia é requisito de contratação! hehehehehe…

Abraços,

[jspaulonciParticipante]

Vieri, como que eu faço pra simular uma perda de datafile com a base no ar ?

Abraços
Spaulonci

[Marcos BragaParticipante]

[quote=”jspaulonci”:2iw4n3cw]Vieri, como que eu faço pra simular uma perda de datafile com a base no ar ?[/quote]

Essa é fácil.

Copia qualquer arquivo para dentro do teu datafile ou um simples:

echo oi >>/path/datafile.dbf

Funciona que é uma belezura. Na próxima vez que precisar utilizar o datafile (qualquer query de consulta, por exemplo) vai aparecer um erro.

Não vou aconselhar apagar o datafile no linux (rm) porque, as vezes, é necessário reiniciar o host para funcionar, porque o linux trabalha com ponteiros. Há um post interessantíssimo sobre recuperação de datafiles em linux com o banco online que funciona 100%.

Atenção para não fazer esse procedimento em datafiles do SYS, SYSTEM rssssss.

[]s
Braga

[Autor]

Posts