RE: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Boa tarde Edinilson, Bem, os scripts estão bem padrão mesmo, comece por aí. Simples e direto, depois vc vai incrementando. Como vc está sem paralelismo, o erro de archive copiado e removido não vai aparecer. Se vc ativar o paralelismo, lembre-se de fazer o backup archivelog separado. Eu colocaria aí uma pequena modificação. Na linha do backup database adicione: filesperset 4; Isto fará com que cada set contenha somente 4 datafiles. Ajuda a ficar mais didático no restore, pois vc vê poucos arquivos sendo "enchidos" por vez. Teste aí para visualizar a diferença. Para melhoria do seu backup, vai pensando em fazer um esquema onde o script vai enviar email prá vc ao fim do backup, anexando o log do Rman (gostou do desafio?). Não é tão complexo e fica muito bom. Nos testes de restore/recover, minha sugestão é que vc documente para ser o seu "Manual de Backup e Restore", um fichário a ser mantido em constante atualização que vc poderá documentar todos os processos, tornando-se o seu padrão para implementar um backup que será funcional e bem documentado. Nos seus testes, tá faltando colocar ASM, vc encara??? Mais no futuro, pense em BCT (block change tracking), dá uma olhadinha aqui: http://www.pythian.com/documents/Pythian-oracle-block-change.pdf http://www.pythian.com/documents/Pythian-oracle-block-change.pdf https://forums.oracle.com/thread/1127625 https://forums.oracle.com/thread/1127625 Bons estudos. []'s Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit
RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Fala Ederson,
Criei um Banco (15GB) para ficar testando melhor o RMAN.
Sim, achei um artigo para criar os arquivos do backup com Nome do Database,
Timestamp e numero do backupset.
Então, comecei do zero e fui , montando meu script e gostaria se possivel voce
validar.
Backup Semanal
ORACLE_SID=dbSFWh
ORACLE_HOME=/d01/app/oracle/product/11gR2
PATH=/d01/app/oracle/product/11gR2/bin
rman target=/ log=/d01/backup/logs/bkp_semanal_dbSFWh.log << EOF
CROSSCHECK BACKUP;
CROSSCHECK ARCHIVELOG ALL;
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'/d01/backup/dbSFWh/%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
'/d01/backup/dbSFWh/BKP_%d_%t_%s.rman' MAXPIECESIZE 5 G;
RUN {
BACKUP INCREMENTAL LEVEL 0 DATABASE;
}
delete noprompt obsolete;
EXIT;
EOF
Backup Diario:
ORACLE_SID=dbSFWh
ORACLE_HOME=/d01/app/oracle/product/11gR2
PATH=/d01/app/oracle/product/11gR2/bin
rman target=/ log=/d01/backup/logs/bkp_diario_dbSFWh.log << EOF
CROSSCHECK BACKUP;
CROSSCHECK ARCHIVELOG ALL;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'/d01/backup/dbSFWh/%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
'/d01/backup/dbSFWh/BKP_%d_%t_%s.rman' MAXPIECESIZE 5 G;
RUN {
BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
}
delete noprompt obsolete;
EXIT;
EOF
Já executei esses dois Backup.
Aguardo seus comentário, pois quero simular um disatre (rsrsrs). Irei tirar o
banco do ar, e simular que perdi meu storage ou o disco, perdi tudo.
Depois quero simular a perda de um datafile...
Grato,
Ednilson Silva
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome
de ederson200...@yahoo.com.br
Enviada em: sexta-feira, 20 de dezembro de 2013 11:22
Para: oracle_br@yahoogrupos.com.br
Assunto: RE: RES: RES: RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Bom dia Edinilson e pessoal do Oracle_BR
Bem, estranhei um pouco a máscara de arquivos que vc configurou, eu sempre usei
%U que gera um nome único, talvez tenha havido uma sobreposição dos arquivos
devido a mesmo nome, isto é, só sobrou o último. Teria sido isto?
BKP_%d_%t_%s.rman
==> %d : nome do database
==> %t : informação de timestamp
==> %s : número do backupset
Bem, ao final então, o backup foi gerado como vc queria? vc agora pode dizer
que seu banco tem backup?
Prá vc ficar mais tranquilo e confiante, dá uma olhada nestes docs Oracle:
http://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmconfb.htm#BRADV89415
http://docs.oracle.com/cd/B12037_01/server.101/b10735/bkup.htm#1020024
http://docs.oracle.com/cd/B12037_01/server.101/b10735/setup.htm
Vc já rodou o backup uma segunda vez e conferiu os logs? ta tudo certo agora?
já pode partir para o RESTORE de um destes backups?
Se aparecer algo estranho, manda para o grupo.
[]'s
Ederson Elias
DBA Oracle
http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
Labor improbus omnia vincit
RE: RES: RES: RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Bom dia Edinilson e pessoal do Oracle_BR Bem, estranhei um pouco a máscara de arquivos que vc configurou, eu sempre usei %U que gera um nome único, talvez tenha havido uma sobreposição dos arquivos devido a mesmo nome, isto é, só sobrou o último. Teria sido isto? BKP_%d_%t_%s.rman ==> %d : nome do database ==> %t : informação de timestamp ==> %s : número do backupset Bem, ao final então, o backup foi gerado como vc queria? vc agora pode dizer que seu banco tem backup? Prá vc ficar mais tranquilo e confiante, dá uma olhada nestes docs Oracle: http://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmconfb.htm#BRADV89415 http://docs.oracle.com/cd/B12037_01/server.101/b10735/bkup.htm#1020024 http://docs.oracle.com/cd/B12037_01/server.101/b10735/setup.htm Vc já rodou o backup uma segunda vez e conferiu os logs? ta tudo certo agora? já pode partir para o RESTORE de um destes backups? Se aparecer algo estranho, manda para o grupo. []'s Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit
RES: RES: RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Ederson, Muito estranho então. RMAN> show all; using target database control file instead of recovery catalog RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/d01/backup/prod/%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 5 BACKUP TYPE TO COMPRESSED BACKUPSET; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/d01/backup/prod/BKP_%d_%t_%s.rman' MAXPIECESIZE 10 G; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/d01/backup/prod/snapcf_prod.f'; Estava acompanhando, e quando o primeiro arquivo *.rman atingiu 10G, ele simplesmente sumiu. Acabei subescrevendo o arquivo de log, coloquei para gerar novamente o backup full, com essa nova alteração que voce passou levou 3 horas, fiquei impressionado. Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de ederson200...@yahoo.com.br Enviada em: quarta-feira, 18 de dezembro de 2013 10:12 Para: oracle_br@yahoogrupos.com.br Assunto: RE: RES: RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN Edinilson, O destino dos backups, vc confere e configura com SHOW ALL e se não esver correto, basta rodar: CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/d01/backup/%F'; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/d01/backup/%U' MAXPIECESIZE 10 G; Neste diretório (/d01/backup), devem permanecer os arquivos ao fim do backup, senão eles foram removidos por outro processo. Inclusive, vc pode monitorar os arquivos sendo "escritos" durante a execução do rman da outra janela, abrindo outra sessão TTY ou putty e fazendo: $ cd /d01/backup $ watch -d ls -lt Verifica o conteúdo do arquivo gerado na linha (confira o nome q vc colocou): rman target=/ log=/home/oracle/bkp03_rman.log << EOF Qualquer coisa, coloca o conteúdo do arquivo no corpo da mensagem. []'s Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit [As partes desta mensagem que não continham texto foram removidas]
RE: RES: RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Edinilson, O destino dos backups, vc confere e configura com SHOW ALL e se não esver correto, basta rodar: CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/d01/backup/%F'; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/d01/backup/%U' MAXPIECESIZE 10 G; Neste diretório (/d01/backup), devem permanecer os arquivos ao fim do backup, senão eles foram removidos por outro processo. Inclusive, vc pode monitorar os arquivos sendo "escritos" durante a execução do rman da outra janela, abrindo outra sessão TTY ou putty e fazendo: $ cd /d01/backup $ watch -d ls -lt Verifica o conteúdo do arquivo gerado na linha (confira o nome q vc colocou): rman target=/ log=/home/oracle/bkp03_rman.log << EOF Qualquer coisa, coloca o conteúdo do arquivo no corpo da mensagem. []'s Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit
RES: RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Ederson, Desculpe minha ignorancia, mas algo que não entendi muito bem, o backup estava sendo gerado em /d01/backup, ao final esses arquivos sumiram, procede? Os archive log, realmente não foram deletados ao final. Quero antes conseguir fazer um backup full 100%, depois irei focar nos backups incremental e depois restore. Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de ederson200...@yahoo.com.br Enviada em: quarta-feira, 18 de dezembro de 2013 09:29 Para: oracle_br@yahoogrupos.com.br Assunto: RE: RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN Edinilson, Os archivelogs podem ser deletados após serem gravados em um backuppiece pelo comando "backup archivelog all", esta é mesmo a intenção. A alteração que fiz no script 2 separa o backup datafiles de archivelog, para que o processo que iniciar a cópia dos datafiles em paralarelo, isto é, mais de um datafile sendo copiado simultâneo, não concorra com o archivelog. Partindo da premissa que um archivelog é pequeno e será gravado mais rapidamente que um datafile. Separando estas cópias, acredito que minimiza o problema de já ter removido o arquivo em outro processo. O próximo passo é implementar o backup incremental diário. FASE 2: muito importante completar um RESTORE deste backup com diversos cenários de crash. Este tópico me interessa muito, pois eu passo o dia neste cenário em minhas atividades diárias. Releve aí se eu fui redundante nas respostas. Se precisar e eu souber, ajudo com prazer (senão, aproveito para estudar uma nova situação). []' s Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit
RE: RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Edinilson, Os archivelogs podem ser deletados após serem gravados em um backuppiece pelo comando "backup archivelog all", esta é mesmo a intenção. A alteração que fiz no script 2 separa o backup datafiles de archivelog, para que o processo que iniciar a cópia dos datafiles em paralarelo, isto é, mais de um datafile sendo copiado simultâneo, não concorra com o archivelog. Partindo da premissa que um archivelog é pequeno e será gravado mais rapidamente que um datafile. Separando estas cópias, acredito que minimiza o problema de já ter removido o arquivo em outro processo. O próximo passo é implementar o backup incremental diário. FASE 2: muito importante completar um RESTORE deste backup com diversos cenários de crash. Este tópico me interessa muito, pois eu passo o dia neste cenário em minhas atividades diárias. Releve aí se eu fui redundante nas respostas. Se precisar e eu souber, ajudo com prazer (senão, aproveito para estudar uma nova situação). []' s Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit
RES: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Ederson,
Alterei o script conforme sua proposta, acontece que ao final os arquivos foram
deletados.
Ficou só o log.
Grato,
Ednilson Silva
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome
de ederson200...@yahoo.com.br
Enviada em: terça-feira, 17 de dezembro de 2013 14:36
Para: oracle_br@yahoogrupos.com.br
Assunto: RE: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Colega Edinilson,
Esta mensagem refere-se a um arquivo que já foi processado e removido por outro
processo. No seu caso, aconteceu porque vc ativou o parelelismo, veja
exemplo/explicação com detalhes no blog abaixo:
http://pavandba.com/2011/01/18/resolving-ora-19588-archived-log-recid-stamp-is-no-longer-valid/
Com Paralelismo, melhor fazer o backup do archivelog separado do database ou
baixar o nível do paralelismo para um valor onde aconteça o equilíbrio entre os
processos ativos e o seu hardware.
Como chegar ao número mágico? Deu erro? baixe o número do paralelismo. Está
demorando mais para backup_ear em paralelo do que quando era =1? baixe o valor
do paralelismo e vá ajustando.
Eu gosto mais de fazer assim: testar com paralelism=1 e marcar o tempo de full
backup. No dia seguinte, colocar paralelism=2 e rodar novamente marcando o
tempo. Vou parar de subir de um em um quando o backup ficar dentro da janela
que panejei. Se o valor de paralelism já estiver alto (ex: =6), significa que
não vai baixar muito o tempo daí prá frente, pois haverá aumento de processos e
vai gerar uma lentidão pelos demais processos de banco/usuários, prejudicando
ao invés de ajudar.
Portanto, se acontecer de não haver melhora com aumento de paralelismo, eu vou
baixar o valor para um valor, digamos, metade do que está no último teste (=3
portanto) e vou pensar em backup incremental. Um backup full no domingo e
incremental durante a semana. Assim vc terá um bom backup no final de semana,
sem preocupar com a janela de duração do processo e em contrapartida, durante a
semana com o backup incremental, será apenas backup dos archivelogs e será
muito rápido. Lembrando que caso seja criado um novo datafile durante a semana,
ele será reportado como "need backup" e será feito a cópia deste datafile no
primeiro backup incremental.
Fechando, também dei uma estudada sobre este erro e vou sugerir:
Mudar o script:
--Original
RUN {
BACKUP AS COMPRESSED BACKUPSET incremental level 0 DATABASE PLUS ARCHIVELOG
delete all input;
delete noprompt obsolete;
}
--Proposta:
delete noprompt obsolete device type disk;
RUN {
BACKUP AS COMPRESSED BACKUPSET incremental level 0 DATABASE;
crosscheck backup;
crosscheck archivelog all;
backup ARCHIVELOG all;
}
delete noprompt obsolete device type disk;
Testar e homologar. Creio que estes procedimentos devem corrigir o problema.
Ederson Elias
DBA Oracle
http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
Labor improbus omnia vincit
RE: RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Colega Edinilson,
Esta mensagem refere-se a um arquivo que já foi processado e removido por outro
processo. No seu caso, aconteceu porque vc ativou o parelelismo, veja
exemplo/explicação com detalhes no blog abaixo:
http://pavandba.com/2011/01/18/resolving-ora-19588-archived-log-recid-stamp-is-no-longer-valid/
Com Paralelismo, melhor fazer o backup do archivelog separado do database ou
baixar o nível do paralelismo para um valor onde aconteça o equilíbrio entre os
processos ativos e o seu hardware.
Como chegar ao número mágico? Deu erro? baixe o número do paralelismo. Está
demorando mais para backup_ear em paralelo do que quando era =1? baixe o valor
do paralelismo e vá ajustando.
Eu gosto mais de fazer assim: testar com paralelism=1 e marcar o tempo de full
backup. No dia seguinte, colocar paralelism=2 e rodar novamente marcando o
tempo. Vou parar de subir de um em um quando o backup ficar dentro da janela
que panejei. Se o valor de paralelism já estiver alto (ex: =6), significa que
não vai baixar muito o tempo daí prá frente, pois haverá aumento de processos e
vai gerar uma lentidão pelos demais processos de banco/usuários, prejudicando
ao invés de ajudar.
Portanto, se acontecer de não haver melhora com aumento de paralelismo, eu vou
baixar o valor para um valor, digamos, metade do que está no último teste (=3
portanto) e vou pensar em backup incremental. Um backup full no domingo e
incremental durante a semana. Assim vc terá um bom backup no final de semana,
sem preocupar com a janela de duração do processo e em contrapartida, durante a
semana com o backup incremental, será apenas backup dos archivelogs e será
muito rápido. Lembrando que caso seja criado um novo datafile durante a semana,
ele será reportado como "need backup" e será feito a cópia deste datafile no
primeiro backup incremental.
Fechando, também dei uma estudada sobre este erro e vou sugerir:
Mudar o script:
--Original
RUN {
BACKUP AS COMPRESSED BACKUPSET incremental level 0 DATABASE PLUS ARCHIVELOG
delete all input;
delete noprompt obsolete;
}
--Proposta:
delete noprompt obsolete device type disk;
RUN {
BACKUP AS COMPRESSED BACKUPSET incremental level 0 DATABASE;
crosscheck backup;
crosscheck archivelog all;
backup ARCHIVELOG all;
}
delete noprompt obsolete device type disk;
Testar e homologar. Creio que estes procedimentos devem corrigir o problema.
Ederson Elias
DBA Oracle
http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
Labor improbus omnia vincit
Re: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Muito legal! nos mantenha atualizados... informe se o problema foi resolvido e se o tempo de backup foi reduzido ainda mais... []'s Em 17 de dezembro de 2013 08:42, Ednilson Silva escreveu: > > > Ederson, > > Já consegui uma melhora muito boa, com relação a tempo, o backup antes > durava 17 horas para finalizar, com o RMAN caiu para 9 horas. > > No final do LOG ocorreu o erro abaixo, estou pesquisando o que pode ser, > mas se puder ajudar. > > > > channel ORA_DISK_1: starting compressed archive log backupset > > RMAN-03009: failure of backup command on ORA_DISK_1 channel at 12/16/2013 > 22:26:30 > > ORA-19588: archived log recid 403 stamp 834339465 is no longer valid > > channel ORA_DISK_1 disabled, job failed on it will be run on another > channel > > channel ORA_DISK_2: starting compressed archive log backupset > > RMAN-00571: === > > RMAN-00569: === ERROR MESSAGE STACK FOLLOWS === > > RMAN-00571: === > > RMAN-03002: failure of backup plus archivelog command at 12/16/2013 > 22:26:31 > > ORA-19588: archived log recid 403 stamp 834339465 is no longer valid > > > > Fiz algumas alterações agora, coloquei PARALLELISM 5 e MAXPIECESIZE 10 G, > vamos se ganhamos alguma coisa. > > > > Grato, > > Ednilson Silva > > > > *De:* oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] *Em > nome de *ederson200...@yahoo.com.br > *Enviada em:* segunda-feira, 16 de dezembro de 2013 16:36 > *Para:* oracle_br@yahoogrupos.com.br > *Assunto:* RE: RES: RES: [oracle_br] Re: Duvidas Backup RMAN > > > > > > OK Edinilson > > Atenção ao detalhe: esta parte do backup que vc configurou, é o backup > SEMANAL. > > O backup DIARIO é o outro script que faz BACKUP incremental level 1 > DATABASE ... > > > > Não se esqueça que eles trabalham EM DUPLA, precisa agendar os dois, ok? > > > > Lembre-se que vc deve agendar o backup semanal para rodar no DOMINGO > começando pela manhã. > > O backup diário, vc agenda para rodar por volta das 20h que garante que vc > não tenha usuários no sistema. Se a sua operação for 24x7, não faz > diferença o horário do agendamento, escolha o de menor movimento para não > gerar interferência no uso dos sistemas. > > > > []'s > > > > > Ederson Elias > DBA Oracle > http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 > > Labor improbus omnia vincit > > >
RES: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Ederson, Já consegui uma melhora muito boa, com relação a tempo, o backup antes durava 17 horas para finalizar, com o RMAN caiu para 9 horas. No final do LOG ocorreu o erro abaixo, estou pesquisando o que pode ser, mas se puder ajudar. channel ORA_DISK_1: starting compressed archive log backupset RMAN-03009: failure of backup command on ORA_DISK_1 channel at 12/16/2013 22:26:30 ORA-19588: archived log recid 403 stamp 834339465 is no longer valid channel ORA_DISK_1 disabled, job failed on it will be run on another channel channel ORA_DISK_2: starting compressed archive log backupset RMAN-00571: === RMAN-00569: === ERROR MESSAGE STACK FOLLOWS === RMAN-00571: === RMAN-03002: failure of backup plus archivelog command at 12/16/2013 22:26:31 ORA-19588: archived log recid 403 stamp 834339465 is no longer valid Fiz algumas alterações agora, coloquei PARALLELISM 5 e MAXPIECESIZE 10 G, vamos se ganhamos alguma coisa. Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de ederson200...@yahoo.com.br Enviada em: segunda-feira, 16 de dezembro de 2013 16:36 Para: oracle_br@yahoogrupos.com.br Assunto: RE: RES: RES: [oracle_br] Re: Duvidas Backup RMAN OK Edinilson Atenção ao detalhe: esta parte do backup que vc configurou, é o backup SEMANAL. O backup DIARIO é o outro script que faz BACKUP incremental level 1 DATABASE ... Não se esqueça que eles trabalham EM DUPLA, precisa agendar os dois, ok? Lembre-se que vc deve agendar o backup semanal para rodar no DOMINGO começando pela manhã. O backup diário, vc agenda para rodar por volta das 20h que garante que vc não tenha usuários no sistema. Se a sua operação for 24x7, não faz diferença o horário do agendamento, escolha o de menor movimento para não gerar interferência no uso dos sistemas. []'s Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit
RE: RES: RES: [oracle_br] Re: Duvidas Backup RMAN
OK Edinilson Atenção ao detalhe: esta parte do backup que vc configurou, é o backup SEMANAL. O backup DIARIO é o outro script que faz BACKUP incremental level 1 DATABASE ... Não se esqueça que eles trabalham EM DUPLA, precisa agendar os dois, ok? Lembre-se que vc deve agendar o backup semanal para rodar no DOMINGO começando pela manhã. O backup diário, vc agenda para rodar por volta das 20h que garante que vc não tenha usuários no sistema. Se a sua operação for 24x7, não faz diferença o horário do agendamento, escolha o de menor movimento para não gerar interferência no uso dos sistemas. []'s Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit
RES: RES: [oracle_br] Re: Duvidas Backup RMAN
Ederson,
Segue o script que estou executando. Inclusive, é um script que você enviou.
Este backup esta executando desde as 10h00. Lembrando que este banco tem mais
de 700GB.
-rw-r- 1 oracle10 dba 680M Dec 16 10:00 BKP_PROD_834314232_21.rman
-rw-r- 1 oracle10 dba 679M Dec 16 09:59 BKP_PROD_834314232_22.rman
-rw-r- 1 oracle10 dba 458M Dec 16 09:58 BKP_PROD_834314232_23.rman
-rw-r- 1 oracle10 dba 20G Dec 16 12:53 BKP_PROD_834314424_24.rman
-rw-r- 1 oracle10 dba 20G Dec 16 12:43 BKP_PROD_834314424_25.rman
-rw-r- 1 oracle10 dba 2.3G Dec 16 15:54 BKP_PROD_834324244_27.rman
-rw-r- 1 oracle10 dba 2.3G Dec 16 15:54 BKP_PROD_834324840_28.rman
---
ORACLE_SID=prod
ORACLE_HOME=/d01/app/oracle/product/10gR2
PATH=/d01/app/oracle/product/10gR2/bin
rman target=/ log=/d01/backup/bkp_semanal_rman.log << EOF
RUN {
BACKUP AS COMPRESSED BACKUPSET incremental level 0 DATABASE PLUS ARCHIVELOG
delete all input;
delete noprompt obsolete;
}
EXIT;
EOF
---
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'/d01/backup/%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/d01/backup/BKP_%d_%t_%s.rman'
MAXPIECESIZE 20 G;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/d01/app/oracle/product/10gR2/dbs/snapcf_prod.f'; # default
Grato,
Ednilson Silva
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome
de ederson200...@yahoo.com.br
Enviada em: segunda-feira, 16 de dezembro de 2013 15:38
Para: oracle_br@yahoogrupos.com.br
Assunto: RE: RES: [oracle_br] Re: Duvidas Backup RMAN
Edinilson,
Sobre a compactação, o Fernando já respondeu, creio que matou suas dúvidas,
confere?
Um detalhe que não foi falado, é que a ZLIB não vem licenciada banco (mesmo que
seja Enterprise). Para usar, vc precisa da feature "Oracle Advanced
Compression".
Neste link, vc pode conferir sobre isto (e outras dúvidas também):
http://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmconfa.htm#BRADV89466
Separei outro link prá vc, que compara os dois algoritmos:
http://husnusensoy.files.wordpress.com/2008/09/bzip2-and-zlib.pdf
Finalizando, vc colocou a configuração do ambiente, mas faltou postar o script
do RMAN para finalizar a configuração do backup.
Coloca aí que o pessoal avalia a sua proposta.
Ederson Elias
DBA Oracle
http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
Labor improbus omnia vincit
RES: [oracle_br] Re: Duvidas Backup RMAN
Fernando, OK, estou neste momento com um backup em execução desde as 10h00. Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fernando Martins Enviada em: segunda-feira, 16 de dezembro de 2013 15:18 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: Duvidas Backup RMAN Amigo, Respondendo tua pergunta: Posso configurar para compactar este meu backup, ou não há necessidade? Isso quem vai ter que avaliar e decidir é exclusivamente você. Agora leve em consideração que a compactação vai consumir mais tempo e CPU da máquina sim, porém não sei te precisar quanto. Eu aconselho que, se possível, faça testes com os três modos: sem compactação, com compactação baixa (zlib) e com compactação alta (bzip2) e compare os tempos e o tamanho final dos backups, coloque tudo numa balança e decida qual o melhor pra você. Eu estou usando a compactação nativa do RMAN atualmente em um banco de produção e de acordo com minha análise está satisfatória, tanto em tempo como em tamanho de backup (um banco de 377GB ficou com 92GB e levou 1h 18min pra finalizar o backup com parallel 8). A vantagem com relação a compactação depois com gzip/bzip2/compress é que o Rman já gera o backup compactado, não necessitando de uma staging area para compactar. Faça teus testes e depois compartilhe com a gente os resultados. Com relação as demais configuração, me parecem ok. -- Fernando Martins Oracle Database 11g Administrator Certified Professional Oracle Database 10g Real Application Clusters Administrator Certified Expert Oracle Database 10g Administrator Certified Professional Oracle Database 10g Administrator Certified Associate Oracle9i Database Administrator Certified Associate Linux Professional Institute Certfied Level 1 "God grant us the serenity to accept the things we cannot change, courage to change the things we can, and wisdom to know the difference." Em 16 de dezembro de 2013 10:11, Ednilson Silva escreveu: Ederson, Estou testando numa base de homologação. Segui as recomendações sua e do Chiappa. Vejam como ficou. RMAN> show all; RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/d01/backup/%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO COMPRESSED BACKUPSET; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/d01/backup/BKP_%d_%t_%s.rman' MAXPIECESIZE 20 G; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/d01/app/oracle/product/10gR2/dbs/snapcf_prod.f'; # default Estava lendo sobre compactar os backup e existe duas formas, através de BZIP2 ou ZLIB. O ZLIB é mais veloz, mas compacta menos. O BZIP2 é mais lento, mas compacta mais. (http://certificacaobd.com.br/2012/05/31/ocp-11g-capitulo-4-criando-backups- do-rman-parte-2/) Posso configurar para compactar este meu backup, ou não há necessidade? Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de ederson2001br Enviada em: sexta-feira, 13 de dezembro de 2013 18:22 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: Duvidas Backup RMAN Alô colega, Vejamos: -primeiro vc tem que comparar o tempo que gasta o backup simples (paralelismo 1), para depois ir aumentando devagar. -Demorar X horas é relativo ao seu hardware, carga de uso, tipo de armazenamento (storage x local x rede). Aumentar o paralelismo acaba por consumir mais recursos de processamento da CPU e se já estiver com gargalo aí, aumentar o paralelismo poderá demorar mais tempo para rodar os processos, pois haverá mais processos a serem gerenciados para o processador (é preciso considerar o time slice). Uma boa explicação, envolve kernel do Linux e eu vou colar um trecho de um Consultor Linux explicando isso: "Linux operates on the principle of time slice every single process is given a little bit of time for its execution. If the process execution is not completed, then it will be put in a suspended mode till it gets its time slice and after that it continues its execution. The switch between different processes happens so fast that an end user will never be able to visualise it. Let us explain the time slice concept with an example assume that there are two processes and Linux gives each a time slice of two seconds. When two seconds elapse for the first process, it is
RE: RES: [oracle_br] Re: Duvidas Backup RMAN
Edinilson, Sobre a compactação, o Fernando já respondeu, creio que matou suas dúvidas, confere? Um detalhe que não foi falado, é que a ZLIB não vem licenciada banco (mesmo que seja Enterprise). Para usar, vc precisa da feature "Oracle Advanced Compression". Neste link, vc pode conferir sobre isto (e outras dúvidas também): http://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmconfa.htm#BRADV89466 Separei outro link prá vc, que compara os dois algoritmos: http://husnusensoy.files.wordpress.com/2008/09/bzip2-and-zlib.pdf Finalizando, vc colocou a configuração do ambiente, mas faltou postar o script do RMAN para finalizar a configuração do backup. Coloca aí que o pessoal avalia a sua proposta. Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit
Re: [oracle_br] Re: Duvidas Backup RMAN
Amigo, Respondendo tua pergunta: *Posso configurar para compactar este meu backup, ou não há necessidade?* Isso quem vai ter que avaliar e decidir é exclusivamente você. Agora leve em consideração que a compactação vai consumir mais tempo e CPU da máquina sim, porém não sei te precisar quanto. Eu aconselho que, se possível, faça testes com os três modos: sem compactação, com compactação baixa (zlib) e com compactação alta (bzip2) e compare os tempos e o tamanho final dos backups, coloque tudo numa balança e decida qual o melhor pra você. Eu estou usando a compactação nativa do RMAN atualmente em um banco de produção e de acordo com minha análise está satisfatória, tanto em tempo como em tamanho de backup (um banco de 377GB ficou com 92GB e levou 1h 18min pra finalizar o backup com parallel 8). A vantagem com relação a compactação depois com gzip/bzip2/compress é que o Rman já gera o backup compactado, não necessitando de uma staging area para compactar. Faça teus testes e depois compartilhe com a gente os resultados. Com relação as demais configuração, me parecem ok. -- *Fernando Martins* Oracle Database 11g Administrator Certified Professional Oracle Database 10g Real Application Clusters Administrator Certified Expert Oracle Database 10g Administrator Certified Professional Oracle Database 10g Administrator Certified Associate Oracle9i Database Administrator Certified Associate Linux Professional Institute Certfied Level 1 "God grant us the serenity to accept the things we cannot change, courage to change the things we can, and wisdom to know the difference." Em 16 de dezembro de 2013 10:11, Ednilson Silva escreveu: > > > Ederson, > > Estou testando numa base de homologação. > > Segui as recomendações sua e do Chiappa. Vejam como ficou. > > > > RMAN> show all; > > > > RMAN configuration parameters are: > > CONFIGURE RETENTION POLICY TO REDUNDANCY 1; > > CONFIGURE BACKUP OPTIMIZATION ON; > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default > > CONFIGURE CONTROLFILE AUTOBACKUP ON; > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO > '/d01/backup/%F'; > > CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO COMPRESSED > BACKUPSET; > > CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default > > CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default > > CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT > '/d01/backup/BKP_%d_%t_%s.rman' MAXPIECESIZE 20 G; > > CONFIGURE MAXSETSIZE TO UNLIMITED; # default > > CONFIGURE ENCRYPTION FOR DATABASE OFF; # default > > CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default > > CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default > > CONFIGURE SNAPSHOT CONTROLFILE NAME TO > '/d01/app/oracle/product/10gR2/dbs/snapcf_prod.f'; # default > > > > Estava lendo sobre compactar os backup e existe duas formas, através de > BZIP2 ou ZLIB. > > O ZLIB é mais veloz, mas compacta menos. O BZIP2 é mais lento, mas > compacta mais. ( > http://certificacaobd.com.br/2012/05/31/ocp-11g-capitulo-4-criando-backups-do-rman-parte-2/ > ) > > > > Posso configurar para compactar este meu backup, ou não há necessidade? > > > > Grato, > > > > Ednilson Silva > > > > > > *De:* oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] *Em > nome de *ederson2001br > *Enviada em:* sexta-feira, 13 de dezembro de 2013 18:22 > *Para:* oracle_br@yahoogrupos.com.br > *Assunto:* [oracle_br] Re: Duvidas Backup RMAN > > > > > > Alô colega, > > > Vejamos: > -primeiro vc tem que comparar o tempo que gasta o backup simples > (paralelismo 1), para depois ir aumentando devagar. > > -Demorar X horas é relativo ao seu hardware, carga de uso, tipo de > armazenamento (storage x local x rede). Aumentar o paralelismo acaba por > consumir mais recursos de processamento da CPU e se já estiver com gargalo > aí, aumentar o paralelismo poderá demorar mais tempo para rodar os > processos, pois haverá mais processos a serem gerenciados para o > processador (é preciso considerar o time slice). > > Uma boa explicação, envolve kernel do Linux e eu vou colar um trecho de um > Consultor Linux explicando isso: > > "Linux operates on the principle of time slice – every single process is > given a little bit of time for its execution. If the process execution is > not completed, then it will be put in a suspended mode till it gets its > time slice and after that it continues its execution. The switch between > different processes happens so fast that an end user will never be able to > visualise it. > > Let us explain the time slice concept with an example – assume that there > are two proce
RES: [oracle_br] Re: Duvidas Backup RMAN
Ederson, Estou testando numa base de homologação. Segui as recomendações sua e do Chiappa. Vejam como ficou. RMAN> show all; RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/d01/backup/%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO COMPRESSED BACKUPSET; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/d01/backup/BKP_%d_%t_%s.rman' MAXPIECESIZE 20 G; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/d01/app/oracle/product/10gR2/dbs/snapcf_prod.f'; # default Estava lendo sobre compactar os backup e existe duas formas, através de BZIP2 ou ZLIB. O ZLIB é mais veloz, mas compacta menos. O BZIP2 é mais lento, mas compacta mais. (http://certificacaobd.com.br/2012/05/31/ocp-11g-capitulo-4-criando-backups- do-rman-parte-2/) Posso configurar para compactar este meu backup, ou não há necessidade? Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de ederson2001br Enviada em: sexta-feira, 13 de dezembro de 2013 18:22 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: Duvidas Backup RMAN Alô colega, Vejamos: -primeiro vc tem que comparar o tempo que gasta o backup simples (paralelismo 1), para depois ir aumentando devagar. -Demorar X horas é relativo ao seu hardware, carga de uso, tipo de armazenamento (storage x local x rede). Aumentar o paralelismo acaba por consumir mais recursos de processamento da CPU e se já estiver com gargalo aí, aumentar o paralelismo poderá demorar mais tempo para rodar os processos, pois haverá mais processos a serem gerenciados para o processador (é preciso considerar o time slice). Uma boa explicação, envolve kernel do Linux e eu vou colar um trecho de um Consultor Linux explicando isso: "Linux operates on the principle of time slice every single process is given a little bit of time for its execution. If the process execution is not completed, then it will be put in a suspended mode till it gets its time slice and after that it continues its execution. The switch between different processes happens so fast that an end user will never be able to visualise it. Let us explain the time slice concept with an example assume that there are two processes and Linux gives each a time slice of two seconds. When two seconds elapse for the first process, it is moved into the swap area. Now the second process starts to execute. Once its two seconds are over, it will be moved into the swap area. The first process will be reloaded and its execution begins. This switch happens every two seconds until one of the processes finishes." -Considere que o seu backup deve ser feito e ele gasta 17h. Minha proposta: faça um full no domingo e incremental nos demais dias, setando redundancia para 2 ou 3 (caso vc tenha espaço). -Assim, o backup diário será bem rápido, uma vez que será gravado somente os archive logs no backup. -Sobre o tamanho do arquivo, com 50Gb vc teria cerca de 16 arquivos. Imagine que isto vai para fita. Caso vc precise voltar um arquivo deste, a demora será maior que se vc precisar voltar um arquivo de 5Gb. O tempo de gravação total não muda, mas arquivos grandes prejudicam o tempo de retorno. -Tudo é relativo e o tamanho de arquivo pode ser ajustado caso não fique como vc desejaria. Portanto, não creio que vc terá uma receita pronta que sirva para todas as situações. Coloque o valor que desejar e acompanhe. Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit --- Em oracle_br@yahoogrupos.com.br, "Ednilson Silva" escreveu > > Pessoal, > > Estou configurando o RMAN conforme algumas dicas do nosso amigo Ederson e > tenho algumas duvidas. > > Qual o limite de paralelismos que posso colocar no RMAN e tamanho dos > arquivos? > > > > Apenas um exemplo: eu poderia criar 16 paralelismo (channel) de 50GB cada? > > > > RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 16 BACKUP TYPE TO COMPRESSED > BACKUPSET; > > RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/d01/backup/%U' > MAXPIECESIZE 50 G; > > > > Tenho um banco 10gR2 (release 10.2.0.5) Enterprise, e este banco tem 800GB e > esta levando 17 horas para concluir o backup e utiliza muito recurso do > servidor. > > > > Grato, > > > > Ednilson Silva >
[oracle_br] RE: Duvidas Backup RMAN
Bom, primeiro vamos responder à sua pergunta : sim, vc EM TESE poderia setar para 16 (veja na documentação mas o limite máximo, iirc, é de 32), MAS na prática se vc o fizer é ENORME a chance de piorar VIOLENTAMENTE a performance se o seu hardware não suportar. Entenda, quando vc seta uma tarefa para ser feita em PARALELO, vc passa a ter MÚLTIPLAS tasks fazendo I/O ao mesmo tempo (em locais/"pedaços" diferentes dos seus datafiles), e OBVIAMENTE isso gasta CPU (para os processos no SO), gasta RAM (para os buffers), pode gastar banda de rede/comunicação... SE o seu hardware já está no gargalo, vc já tem tasks de usuário consumindo recursos mil, o I/O/CPU/rede/RAM Podem Não dar conta dessas tasks extras, sim ??? Assim sendo : PARALELISMO vc só lança mão se tem CERTEZA que há recursos de hardware desocupados, que possam atender às tasks extras, E o garu de paralelismo depende Fundamentalmente da CAPACIDADE do seu hardware - idealmente vc executaria sem paralelismo (grau 1), depois tentaria com 2 ou 3, depois com 6, e veja que resposta obtém... é Começar ** SIMPLES **, aos Poucos, okdoc ?? Já que vc está preocupado com performance do backup, algumas dicas cabíveis : a. é FUNDAMENTAL que vc obtenha a maior performance possível do teu hardware de I/O (um backup para disco consome principalmente é I/O, mesmo), então vc TEM que : 1. junto com o sysadmin desse ambiente , ver quais discos/controladoras são mais rápidas e/ou estão sendo menos usadas, e dedicar esses caras pro backup 2. TEM que garantir a menor concorrência de I/O possível , então junto com o pessoal da Aplicação, tem que negociar uma janela com o menor processamento possível, re-schedular o que der, etc 3. notar que o seu objetivo é gravar a info em disco Apenas esta vez (um backup dificilmente é lido logo em seguida à gravação), o mais rápido possível, E sem grandes preocupações com manutenção/segurança (já que asap isso vai ir pralguma fita/dispositivo afora o disco), yep ??? Assim, junto com o seu sysadmin E com o pessoal de discos/storage, vc VAI SE ASSEGURAR que o disco/device Não tem Journaling/software-mirroring, que ESTÁ sendo acessado via I/O Asynchronous E em Direct-mode I/O (assim bypassando caches do SO E permitindo múltiplos I/Os simultâneos)... Esse objetivo é DIAMETRALMENTE OPOSTO aos defaults do SO, que é jogar para cache tudo que foi acessado para tentar acelerar os PRÓXIMOS I/Os que forem repetidos, fique atento Isso é ainda mais importante quando eu vejo que vc está com um destino /d01/backup/nãoseioque : TIPICAMENTE isso indica um FILESYSTEM em uso, e na maioria dos filesystems nem asunc I/O nem Direct I/O são default 4. LOGICAMENTE, já que o RMAN roda em parte dentro do database (sempre há uma fase de LEITURA dentro do disco antes da fase de gravação externa), o DATABASE preferencialmente deve estar bem configurado, ie : com Asynch I/O e Direct I/O ativos, tablespaces (preferencialmente LMT!!!) com extent sizes apropriados/alinhados com o tamanho máximo de I/o no seu ambiente, SGA e PGA adequados, nenhum WAIT interno do próprio RDBMS despontando entre os TOPs (PRINCIPALMENTE waits referentes à commit ou ação do DBWR!!), a menor taxa de buffer busy e correlatos, etc... b. além de paralelismo, experimente também no RMAN ativar a BACKUP OPTIMIZATION, desative encriptação, não tenha múltiplas cópias nem dos archives nem dos datafiles backupeados Mais uma vez, isso diminui a segurança MAS como esse backup vai ASAP para fita, não vejo grandes riscos aí... c. também faz parte do teu trabalho diminuir AO MÁXIMO o volume a ser backupeado : isso implica em testar backups Incrementais, não backupear datafiles históricos/read-only todas as vezes Opções mais arriscadas, como não backupear tablespaces que só contém índices (extraindo ao invés só os DDLs) podem ser consideradas, também, SE vc tem tablespaces com separações, SE vc está á vontade em aceitar o trabalho e o risco maiores que isso implica E SE o SLA para o restore for bm liberal... d. nessa fase que vc está, de testes, setup e verificações iniciais, as views/tabelas internas de wait em geral (e as de RMAN em particular) podem ter ser Extremamente úteis : google e localiza o paper "Recovery Manager (RMAN) Performance Tuning Best Practices" e de ums estudada nos manuais de Adm inistração e Tuning que vc acha várias refs para elas todas []s Chiappa
[oracle_br] Re: Duvidas Backup RMAN
Alô colega, Vejamos: -primeiro vc tem que comparar o tempo que gasta o backup simples (paralelismo 1), para depois ir aumentando devagar. -Demorar X horas é relativo ao seu hardware, carga de uso, tipo de armazenamento (storage x local x rede). Aumentar o paralelismo acaba por consumir mais recursos de processamento da CPU e se já estiver com gargalo aí, aumentar o paralelismo poderá demorar mais tempo para rodar os processos, pois haverá mais processos a serem gerenciados para o processador (é preciso considerar o time slice). Uma boa explicação, envolve kernel do Linux e eu vou colar um trecho de um Consultor Linux explicando isso: "Linux operates on the principle of time slice every single process is given a little bit of time for its execution. If the process execution is not completed, then it will be put in a suspended mode till it gets its time slice and after that it continues its execution. The switch between different processes happens so fast that an end user will never be able to visualise it. Let us explain the time slice concept with an example assume that there are two processes and Linux gives each a time slice of two seconds. When two seconds elapse for the first process, it is moved into the swap area. Now the second process starts to execute. Once its two seconds are over, it will be moved into the swap area. The first process will be reloaded and its execution begins. This switch happens every two seconds until one of the processes finishes." -Considere que o seu backup deve ser feito e ele gasta 17h. Minha proposta: faça um full no domingo e incremental nos demais dias, setando redundancia para 2 ou 3 (caso vc tenha espaço). -Assim, o backup diário será bem rápido, uma vez que será gravado somente os archive logs no backup. -Sobre o tamanho do arquivo, com 50Gb vc teria cerca de 16 arquivos. Imagine que isto vai para fita. Caso vc precise voltar um arquivo deste, a demora será maior que se vc precisar voltar um arquivo de 5Gb. O tempo de gravação total não muda, mas arquivos grandes prejudicam o tempo de retorno. -Tudo é relativo e o tamanho de arquivo pode ser ajustado caso não fique como vc desejaria. Portanto, não creio que vc terá uma receita pronta que sirva para todas as situações. Coloque o valor que desejar e acompanhe. Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit --- Em oracle_br@yahoogrupos.com.br, "Ednilson Silva" escreveu > > Pessoal, > > Estou configurando o RMAN conforme algumas dicas do nosso amigo Ederson e > tenho algumas duvidas. > > Qual o limite de paralelismos que posso colocar no RMAN e tamanho dos > arquivos? > > > > Apenas um exemplo: eu poderia criar 16 paralelismo (channel) de 50GB cada? > > > > RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 16 BACKUP TYPE TO COMPRESSED > BACKUPSET; > > RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/d01/backup/%U' > MAXPIECESIZE 50 G; > > > > Tenho um banco 10gR2 (release 10.2.0.5) Enterprise, e este banco tem 800GB e > esta levando 17 horas para concluir o backup e utiliza muito recurso do > servidor. > > > > Grato, > > > > Ednilson Silva >
