Menu de navegação

[rmanParticipante]

@felipeg

Quando tiver um tempinho vou ler o artigo, além de reformar, quero otimizar e reduzir o tempo de backup…

[EmersonmartinsParticipante]

@felipeg @rman

Sei que backup com RMAN depende muito do seu ambiente, da volumetria de dados, tamanho, importância e janela de recuperação definida no backup.

Agora so por questão de curiosidade, nesse caso eu recomendaria ver as opções abaixo exibida no show all do rman.Só á titulo de informação.

1 – CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
certifica que o RMAN mantém todos os backups necessários para recuperar o banco de dados a qualquer momento nos últimos sete dias

2 – CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
Minha sugestão é aumentar isso ai!Porque?Essa é a configuração que defini a quantidade de copias de cada arquivo de dados;

Mesmo sendo seguro os backups com RMAN, mas digamos que o seu ultimo backup foi inválido, como você vai resolver?E a aplicação dos archives??

Emerson Martins
DBA JR
emersonmartinsdba.blogspot.com

[felipegParticipante]

Emerson,

Uma coisa que devo admitir que me intrigou é o fato de ser realizado um backup diário e, devido a política de retenção, todos os outros serem deletados (o que acontece se eu tiver que voltar um schema deletado a 5 dias?), porém, como o @Rman mesmo disse, estas políticas serão revistas.

Concordo com as suas observações, principalmente em se tratando de um ambiente de produção, porém, temos que levantar dois pontos:

• Este parâmetro deveria ser alterado, na minha opinião, apenas depois de criada uma política corporativa de Backup que deve definir a janela de retenção destes backups.
• Para qualquer valor acima de 7 dias em retenção já é necessário se atentar ao parâmetro CONTROL_FILE_RECORD_KEEP_TIME (caso o ControlFile seja o repositório das informações do RMAN).

Outra coisa, independente da Janela, mesmo se você possuir apenas um backup e os archives certinhos você pode trazer a base a qualquer ponto dentro deste tempo (obviamente que com mais backups menor a chance de falha e maior a tolerância de tempo para recuparação) mas é OBRIGAÇÃO do DBA garantir que os seus backups estejam íntegros.

Atenciosamente,
Felipe.

[rmanParticipante]

@felipeg

Acabei não mencionando, mas existe o backup diário em fita, desta forma é possível voltar os 5 dias questionado. Está meio estranho, mas além da politica de retenção do RMAN, existe a politica de retenção da fita.

[felipegParticipante]

@Rman

Mas quando você usa o delete obsolete ele apaga dos registros do RMAN as informações sobre aquele backup (Pois conforme configurado nas suas políticas ele não é mais necessário).

Pra conferir, entre no prompt do RMAN e dê um LIST BACKUP, veja o que ele lista (arquivos e datas)… apenas o último backup feito e os archives backupeados depois disso correto?

Ou seja, o que você tem em fita não são backups, são arquivos sem utilidade, pois o RMAN não saberia o que fazer com eles.

Cara, vocês já fizeram alguma simulação de restore? 😯

Atenciosamente,
Felipe.

[rmanParticipante]

@felipeg

Restaurando o control file do backup o RMAN não terá todas as informações para proceder ?

Foi realizado um restore em uma segunda máquina desta forma, mas na mesma máquina nunca foi feito.

Realmente o que eu tenho em fita é um backup invalido ?


RMAN> list backup;

using target database control file instead of recovery catalog

List of Backup Sets

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3474 Full 18.89G DISK 01:32:35 30-NOV-11
BP Key: 3474 Status: AVAILABLE Compressed: YES Tag: TAG20111130T1801 10
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_301111/backu pfullSMT_20111130_cpmsviv6_1_1.dbf
List of Datafiles in backup set 3474
File LV Type Ckp SCN Ckp Time Name

---

2 Full 1237241728 30-NOV-11 /oracle/archivelog/undotbs101.dbf
5 Full 1237241728 30-NOV-11 /oracle/data/ts_tributos01.dbf
8 Full 1237241728 30-NOV-11 /oracle/idx/ts_tributos_idx01.dbf
11 Full 1237241728 30-NOV-11 /oracle/archivelog/undotbs102.dbf
12 Full 1237241728 30-NOV-11 /oracle/archivelog/undotbs103.dbf
13 Full 1237241728 30-NOV-11 /oracle/idx2/ts_tributos_idx04.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3475 Full 11.59G DISK 01:10:52 30-NOV-11
BP Key: 3475 Status: AVAILABLE Compressed: YES Tag: TAG20111130T1801 10
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_301111/backu pfullSMT_20111130_cqmsvocq_1_1.dbf
List of Datafiles in backup set 3475
File LV Type Ckp SCN Ckp Time Name

---

6 Full 1237274307 30-NOV-11 /oracle/data/ts_tributos02.dbf
9 Full 1237274307 30-NOV-11 /oracle/idx/ts_tributos_idx02.dbf
14 Full 1237274307 30-NOV-11 /oracle/idx2/ts_tributos_idx05.dbf
17 Full 1237274307 30-NOV-11 /oracle/data2/ts_tributos05.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3476 Full 8.73G DISK 00:49:51 30-NOV-11
BP Key: 3476 Status: AVAILABLE Compressed: YES Tag: TAG20111130T1801 10
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_301111/backu pfullSMT_20111130_crmsvshq_1_1.dbf
List of Datafiles in backup set 3476
File LV Type Ckp SCN Ckp Time Name

---

1 Full 1237279600 30-NOV-11 /oracle/app/oradata/smt/system01.dbf
3 Full 1237279600 30-NOV-11 /oracle/app/oradata/smt/sysaux01.dbf
4 Full 1237279600 30-NOV-11 /oracle/app/oradata/smt/users01.dbf
7 Full 1237279600 30-NOV-11 /oracle/data/ts_tributos03.dbf
10 Full 1237279600 30-NOV-11 /oracle/idx/ts_tributos_idx03.dbf
16 Full 1237279600 30-NOV-11 /oracle/idx2/ ts_tributos_idx06.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3477 Full 2.86G DISK 00:13:33 30-NOV-11
BP Key: 3477 Status: AVAILABLE Compressed: YES Tag: TAG20111130T1801 10
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_301111/backu pfullSMT_20111130_csmsvvfd_1_1.dbf
List of Datafiles in backup set 3477
File LV Type Ckp SCN Ckp Time Name

---

15 Full 1237283235 30-NOV-11 /oracle/data/ts_tributos04.dbf

BS Key Size Device Type Elapsed Time Completion Time

---

3478 606.64M DISK 00:01:52 30-NOV-11
BP Key: 3478 Status: AVAILABLE Compressed: YES Tag: TAG20111130T2148 23
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_301111/Archi velog_SMT_ctmt0098.arc

List of Archived Logs in backup set 3478
Thrd Seq Low SCN Low Time Next SCN Next Time

---

1 12996 1236294768 29-NOV-11 1236530880 29-NOV-11
1 12997 1236530880 29-NOV-11 1236531255 29-NOV-11
1 12998 1236531255 29-NOV-11 1236924015 30-NOV-11
1 12999 1236924015 30-NOV-11 1237134719 30-NOV-11
1 13000 1237134719 30-NOV-11 1237283957 30-NOV-11

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3479 Full 8.14M DISK 00:00:00 30-NOV-11
BP Key: 3479 Status: AVAILABLE Compressed: NO Tag: TAG20111130T21502 0
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_301111/contr olfile.ctlc-772358457-20111130-00
Control File Included: Ckp SCN: 1237284173 Ckp time: 30-NOV-11
SPFILE Included: Modification time: 30-NOV-11

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3480 Full 18.89G DISK 01:26:49 01-DEC-11
BP Key: 3480 Status: AVAILABLE Compressed: YES Tag: TAG20111201T1801 11
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_011211/backu pfullSMT_20111201_cvmt4rn7_1_1.dbf
List of Datafiles in backup set 3480
File LV Type Ckp SCN Ckp Time Name

---

2 Full 1237887523 01-DEC-11 /oracle/archivelog/undotbs101.dbf
5 Full 1237887523 01-DEC-11 /oracle/data/ts_tributos01.dbf
8 Full 1237887523 01-DEC-11 /oracle/idx/ts_tributos_idx01.dbf
11 Full 1237887523 01-DEC-11 /oracle/archivelog/undotbs102.dbf
12 Full 1237887523 01-DEC-11 /oracle/archivelog/undotbs103.dbf
13 Full 1237887523 01-DEC-11 /oracle/idx2/ts_tributos_idx04.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3481 Full 11.47G DISK 01:10:53 01-DEC-11
BP Key: 3481 Status: AVAILABLE Compressed: YES Tag: TAG20111201T1801 11
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_011211/backu pfullSMT_20111201_d0mt50q7_1_1.dbf
List of Datafiles in backup set 3481
File LV Type Ckp SCN Ckp Time Name

---

6 Full 1237898276 01-DEC-11 /oracle/data/ts_tributos02.dbf
9 Full 1237898276 01-DEC-11 /oracle/idx/ts_tributos_idx02.dbf
14 Full 1237898276 01-DEC-11 /oracle/idx2/ts_tributos_idx05.dbf
17 Full 1237898276 01-DEC-11 /oracle/data2/ts_tributos05.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3482 Full 8.74G DISK 00:51:19 01-DEC-11
BP Key: 3482 Status: AVAILABLE Compressed: YES Tag: TAG20111201T1801 11
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_011211/backu pfullSMT_20111201_d1mt54v7_1_1.dbf
List of Datafiles in backup set 3482
File LV Type Ckp SCN Ckp Time Name

---

1 Full 1237904382 01-DEC-11 /oracle/app/oradata/smt/system01.dbf
3 Full 1237904382 01-DEC-11 /oracle/app/oradata/smt/sysaux01.dbf
4 Full 1237904382 01-DEC-11 /oracle/app/oradata/smt/users01.dbf
7 Full 1237904382 01-DEC-11 /oracle/data/ts_tributos03.dbf
10 Full 1237904382 01-DEC-11 /oracle/idx/ts_tributos_idx03.dbf
16 Full 1237904382 01-DEC-11 /oracle/idx2/ ts_tributos_idx06.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3483 Full 2.86G DISK 00:13:16 01-DEC-11
BP Key: 3483 Status: AVAILABLE Compressed: YES Tag: TAG20111201T1801 11
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_011211/backu pfullSMT_20111201_d2mt57vl_1_1.dbf
List of Datafiles in backup set 3483
File LV Type Ckp SCN Ckp Time Name

---

15 Full 1237908212 01-DEC-11 /oracle/data/ts_tributos04.dbf

BS Key Size Device Type Elapsed Time Completion Time

---

3484 458.72M DISK 00:01:07 01-DEC-11
BP Key: 3484 Status: AVAILABLE Compressed: YES Tag: TAG20111201T2144 05
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_011211/Archi velog_SMT_d3mt58p6.arc

List of Archived Logs in backup set 3484
Thrd Seq Low SCN Low Time Next SCN Next Time

---

1 13000 1237134719 30-NOV-11 1237283957 30-NOV-11
1 13001 1237283957 30-NOV-11 1237284185 30-NOV-11
1 13002 1237284185 30-NOV-11 1237640627 01-DEC-11
1 13003 1237640627 01-DEC-11 1237908806 01-DEC-11

BS Key Type LV Size Device Type Elapsed Time Completion Time

---

3485 Full 8.14M DISK 00:00:00 01-DEC-11
BP Key: 3485 Status: AVAILABLE Compressed: NO Tag: TAG20111201T21452 2
Piece Name: /oracle/backup1/backupRMAN/smt/backup_FULL_RMAN_011211/contr olfile.ctlc-772358457-20111201-00
Control File Included: Ckp SCN: 1237908994 Ckp time: 01-DEC-11
SPFILE Included: Modification time: 01-DEC-11


[felipegParticipante]

Ah, veja você, esqueci do backup do controlfile, desculpe.

Quando você testou em outra máquina usou o último backup ou um outro mais antigo?

Atenciosamente,
Felipe.

[rmanParticipante]

@felipeg

Foi o ultimo, foi feita uma instalação nova do Oracle 10g R2, foi feita a atualização para 10.2.0.4.0 para igualar as versões, então foi feito o restore do spfile, o restore do control file, então veio o restore e recover.

Mas o ideal não é forma que esta sendo feito ne ?

[fabiogaleraParticipante]

Sinceramente ?

rman,

Definir uma boa estratégia de Backup parece ser fácil, mas muitas das vezes não é. Tudo irá depender do seu dia-a-dia e inclusive das pessoas que você trabalha. Já trabalhei em empresa que possuiam desenvolvedores aplicacionais “estrelas”, faziam o que queriam, eventualmente fazia jobs e mais jobs de data load semanais que incluiam 100GB de informações na Base de Dados, sem ao menos informar os DBAs. Neste mesmo caso, cheguei a alterar os backups dos archives de 4 em 4 horas, para 3 em 3, para 2 em 2, 1 em 1 … e depois mudei tudo de tão nervoso fiquei por ser acordado todo fim de semana de madrugada por causa de área de archive.

Agora eu respondo sua pergunta quanto a estratégia de Archive.

Eu prefiro criar 2 scripts para schedule, 1 schedulado como deveria ser, 2 em 2, ou 4 em 4 horas … porém, geralmente agendo um para monitorar o espaço em filesystem a cada 10-15 minutos verificando se o filesystem passar de 70% realizar o backup.

Tome cuidado com o ‘ALTER SYSTEM ARCHIVE LOG CURRENT’; no início dos backups de archive. Afinal, se o filesystem estiver 100% cheio, como você irá gerar um archive antes do backup ? Seu backup irá ficar parado pra sempre =)

Eu particularmente verifico a situação do filesystem antes de iniciar o backup, utilizo uma contagem acerca do espaço disponível, dependendo do tamanho da base e a volumetria dos archives nos ultimos tempos …

[rmanParticipante]

@fabiogalera

Pela sua estrategia de 2 jobs, eu entendi que você só faz backup caso a área de archive encher. Mas é essa a ideia ? Se ficar um mês sem encher a área de archive nenhum backup é realizado ?

O backup de archive log não é para garantir que se a partição ou disco da área de archive vier a falhar você tem isso em outro lugar ?

[fabiogaleraParticipante]

Não.

1 – Schedulado periodicamente para fazer backup;
2 – Monitora o filesystem, em casos de urgência, chama o script 1;

[rmanParticipante]

@fabiogalera

Ah sim, agora eu entendi, o segundo job vai garantir se houver uma variação muito grande na geração do archive log, bem pensado.

[jurupocParticipante]

Pessoal para resolver o problema acima não basta adicionar um segundo local para gravar os archives?

[EmersonmartinsParticipante]

😳
Deixa eu ver se entendi direito?

Após efetuado o backup para uma outra mídia externa, seja disco, ou fita através de um Data Protector por exemplo, no caso depois de deletar os backups através do RMAN, Só será possivel fazer o RECOVER caso restaure o controlfile daquele dia onde encontra-se todas as configurações dos backups feitos no dia?

Emerson
DBA Jr
emersonmartinsdba.blogspot.com

[fabiogaleraParticipante]

jurupoc,

Se você habilitar 2, 3 ou 4 destinos, o Oracle vai gerar archives duplicados para todos os LOG_ARCHIVE_DEST ativos. O que irá acontecer é que irá encher os dois filesystem =)

[Autor]

Posts