Menu de navegação

[vieriParticipante]

Caros,

possuo um ambiente de bi 10.2.0.3
single instance, filesystem.
Nada exepcional, exceto pelo complexidade
dos processos de BI(ETL,OWB,Hiperion,Tabelas particionadas)
quem adm um ambiente deste sabe o trabalho que dá,
tanto na adm como no tunning.

Mas o pior de tudo é a estratêgia de backup.

No momento temos um shell que realize um bkp full online,
e mantemos os archive no proprio server durante 3 dias.

Não tenho janela de indisponibilidade 24/7

O problema é que a base já possui quase 1tera e o backup
leva em média 25hrs.

obs: Já peguei o ambiente assim.. rs

Estou pensando em migrar este backup para o RMAN,
mas a minha dúvida é se o tempo irá melhorar,
e qual estratégia e features do rman utilizar.

Para bases OLTP utilizo rman com sucesso,
nivel 0 fds e nivel 1 durante a semana, mas para ambiente de bi não ficaria legal, já perder dados não é problema é questão de reprocessar,
seria um backup full + archives para possiveis crash’s (de preferência que não leve o dia inteiro).

[]s

alguem já passou por situação parecida ou adm alguma base de 1 tera
de bi e poderia relatar a experiência.

abços..

[David SiqueiraParticipante]

Vieri meu velho como sempre trazendo problemas de peso..hehehehe..
Bom podemos contar com a ajuda do nosso amigo Alphamek ( Rodrigo) , mais cara mesmo eu não sendo especialista , acredito que via Rman tu ganhe mais tempo com certeza, uma pelo tipo de algoritmo que o Rman usa para realizar backups e pela enorme quantodade de Features que o RMAN 10g traz , agora essa sua realease 10.2.0.3 não me agrada nada, tem pouco bug ela viu..heheheheh..mais enfim acredito que o Rodrigão possa esclarecer pra ti melhor e definir uma estratgia boa de Backup, mais um nivel 0 e um nivel 1 no meio do dia seria de bom tamanho, mais enfim, vamo deixar pra quem sabe.

Abcs.

David

[Rodrigo AlmeidaParticipante]

Vieri,

Belezinha cara! Trabalhei com BI 2 anos também, eu tinha DW de 12TB que dava trabalho para a galera, porém, antes de mais nada, pelo que tu está passando muitas coisas devem ser revistas, por exemplo:

1) Um BI mesmo, (Falando de Data WareHouse), geralmente é NOARCHIVELOG, pois é uma base apenas de consulta, e feito backup somente no final de semana que tem janela para isso, pois se perder algo, o prórpio processo de ETL pode recuperar os dados perdidos e a instância volta ao normal, pois é só alimentar as tabelas de FATO e suas dimensões, mesmo porque não é normalizado.

A estrategia de backup para o DW era muito influênciado pelo que a empresa fornecia, exemplo, se cair na sexta, nós tinhamos os arquivos de carga de 2 semanas atrás e aplica a carga, e fazia o backup FULL COLD no Domingo. Sem muita frescura.

2) Tive a experiência de ter na mão tb um Data Smart de 2Tb que esse sim estava ARCHIVELOG, porém, antes de qualquer coisa, devemos analisar o que a infra-estrutura da empresa nos oferece, exemplo:

2.1) Unidades de FITA ou Storage para backup?
2.2) Qual a tecnologia que tenho a disposição? DLT, LTO, DDS, Disco e etc…
2.3) Quais os produtos para realizar essa tarefas de backup? Exemplo, Netbackup, Tivoli, ArcServer e etc…
2.4) Possui BCV, Mirror ou algum outro tipo de espelhamento no server?
2.5) Quais as janelas para backup?
2.6) Quais os horários que as cargas são realizadas?
2.7) Qual é o tempo de Dowtime que posso ter no meu DM ou DW?
2. 8) Minha infra de rede? Eu possuo uma rede de backup única para tal tarefa, ou vou precisar competir com os usuários?

Sobre o RMAN como solução!

O RMAN se estiver com uma versão Enterprise no banco pode lhe oferecer diversas outras vantagens sobre os outros produtos, como:

1 – Pode realizar o backup utilizando por natureza o algoritmo NULL COMPRESSION, não copia os EMPTY BLOCK, isso pode diminuir o tamanho do seu backup.

2 – Pode se utilizar a opção BACKUP AS COMPRESSED, isso pode demorar um pouco a mais para realizar o backup e consequentemente consumir mais CPU, por isso é importante ter as respostas das perguntas de cima para poder utilziar.

3 – O RMAN pode alocar para você no mesmo script canais de comunicação para backup em DISCO e FITA, ou seja, pode ser utilizar realizar o backup do banco para DISCO e mandar os archives para FITA para ganhar espaço.

4 – Caso não tenha disponibilidade e a taxa de carga é muito alto, o RMAN permite realizar o backup com um determinado periodo de tempo, ou seja, tu pode falar que tem somente 6 horas de janela em um determinado horario, e caso não seja feito ele aborta o backup.

4.1 – Com essa opção ele pode abortar o seu backup, ou tu ainda pode utilizar a opção BACKUP DURATION 06:00 MINIMIZE TIME PARTIAL DATABASE, e tu que foi feito de backup, ser reaproveitado!

5 – Tem a opção de janela de backup como acima, e utilizar a opção MINIMIZE LOAD, ou seja, seu banco de dados pode etar com alta taxa de carga e mesmo precisando de backup, o RMAN irá realizar com poucos recursos disponíveis. Porém, nesse modo o backup demora muito mais!

6 – A vantagem básica do RMAN, com ARCHIVELOG, tu pode trabalhar com até 4 níveis de backup incrementais, ou seja, dependendo da sua estratégia, se torna fácil a sua recuperação!

7 – O RMAN lhe permite realizar limitado por backup piece, ou seja, se eu quiser em algum momento realizar todo o meu backup para FITA, e minha fita é limitado em 400GB, posso mandar de 400GB em 400GB. E olha que bom, se tenho uma infra de rede específica para backup e trabalhar com as opções acima, tem grande chance de seu um SUCESSO!

8 – O RMAN trabalha com catálogo, não preciso falar nada. =D

9 – Com o RMAN tu tem a opção de fornecer consistência e garantia de restauração do seu backup, ou seja, pode utilizar o VALIDATE CHEC LOGICAL DATABASE e RESTORE DATABASE PREVIEW!!! Nem comento!

10 – Pode utilizar BMR! Ou Seja, Block Media Recover, imagina uma tabela de fato de 300GB com um bloco de dados corrompido, mesmo que seja particionada e afete somente uma partição, imagina o trabalho que será recuperar isso e não impactar a aplicação, enquanto tu pode utilizar somente o comando BLOCKRECOVER CORRUPTION LIST.

11 – E tem mais umas dezenas de coisas que ele pode lhe oferecer, é que já estou puxando muito o saco do RMAN e logo logo os caras vão me chamar para ser vendedor do produto! hehehehe.

Agora, outro ponto importante.

Eu disse sobre conhecer sua infra-estrutura e um pouco do RMAN, porém quais as estratégias de backup se será realizado, como:

1) Se precisar recuperar o banco inteiro, leva quanto tempo?
2) Se perder uma tabela, como posso recuperar ela?
3) Se tenha alguma corrupção lógica, o que podemos fazer?
4) Meu backup é 100% restaurável?
5) Vou precisar de backup lógico?
6) E as procedures, packages e functions, o que faço?

Sobre aplicar isso tecnicamente!

O Ideal é todo fim de semana é tem um BACKUP FULL CONSISTENTE, ou seja, ALTER SYSTEM ARCHIVE LOG CURRENT e depois BACKUP INCREMENTEL LEVEL 0 DATABASE INCLUDE CURRENT CONTROLFILE.

Configar os banco para os parâmertos default do RMAN.

Mesclar backup Nível 0, 1 e 2 durante a semana.

Veja a quantidade de espaço que você tem disponível para os archives, talves você possa habilitar mais uma área de ARCHIVES e a cada 1 hora manda eles para FITA por segurança.

E tem mais dezenas de coisas Vieri, leva isso em consideração e conforme vai surgindo as dúvidas, vai postando…

Abraços,
Rodrigo Almeida

[vieriParticipante]

Fala Rodrigão.

Respondendo as perguntas:

2.1) Unidades de FITA ou Storage para backup?
storage
2.2) Qual a tecnologia que tenho a disposição? DLT, LTO, DDS, Disco e etc…
disco
2.3) Quais os produtos para realizar essa tarefas de backup? Exemplo, Netbackup, Tivoli, ArcServer e etc…
Produto deste genêro nenhum é tudo na munheca mesmo
2.4) Possui BCV, Mirror ou algum outro tipo de espelhamento no server?
não
2.5) Quais as janelas para backup?
seg à sab(somente on-line durante o dia), domingo(toral)
2.6) Quais os horários que as cargas são realizadas?
das 9hrs até 6 da manhã . é mto etl…
2.7) Qual é o tempo de Dowtime que posso ter no meu DM ou DW?
Não gosto nem de pensar em downtime… rs de preferência caso precise algum dia, algumas horas…
2. 8) Minha infra de rede? Eu possuo uma rede de backup única para tal tarefa, ou vou precisar competir com os usuários?
Irá competir com outros usuário, e com outros bkp’s.

1) Se precisar recuperar o banco inteiro, leva quanto tempo?
Imagino que umas 10horas sendo otimista.
2) Se perder uma tabela, como posso recuperar ela?
Cancelaram o dump por falta de espaço.Vou tentar reativar.
3) Se tenha alguma corrupção lógica, o que podemos fazer?
Restore do datafile corrompido.
4) Meu backup é 100% restaurável?
Não tive area para testar.
5) Vou precisar de backup lógico?
não é o + importante no momento.
6) E as procedures, packages e functions, o que faço?
tem copia em homologação.

Estava pensando em backup em paralello,compress,full,on-line diariamente,archivelog, começando apos os ETL’s,
no proprio server, no fim transferia tudo para o servidor de bkp ou direto para o servidor de bkp?Oque acham?

Indo para mão na masssa:

Aonde enfio o compress neste scrip abaixo?

run {
allocate channel t1 type disk;
allocate channel t2 type disk;
allocate channel t3 type disk;
backup full database tag ‘BKP_BI_FULL’
format ‘/uo1/backup/ora10/full/bkp_full_%d_%t_%s.rman’
backup durrent controlfile tag ‘BKP_CF’
format ‘/uo1/backup/ora10/full/bkp_ctl_%d_%t_%s.rman’
backup spfile tag ‘BKP_SPFILE’
format ‘/uo1/backup/ora10/full/bkp_spfile_%d_%t_%s.rman’
release channel t1;
release channel t2;
release channel t3;
}

Também tenho essa opção abaixo.

run {
allocate channel t1 type disk maxpiecesize = 50G;
backup as compressed backupset incremental level0 database
include current controlfile
plus archivelog
tag ‘bi_bkp_full’
format ‘/uo1/backup/ora10/full/bkp_l0_diario_%d_%t_%s.rman’;
release channel t1;
}

E outros scripts que utilizo em prod mas gostaria de criar um modelo do zero.

Existe diferença entre o incremental level0 e o backup full database ?

Parâmetros.

RMAN configuration parameters are:
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 ‘%F’;
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET; < = paralelismo em 4 como tenhu 4cpu
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/teste/teste_%d_%t_%U.bct';
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/10.2/db_1/dbs/snapcf_bi.f'; # default

Oque posso ajustar ai ?

[]s…

[Rodrigo AlmeidaParticipante]

Vieri,

Segue uma sugestão para o seu backup.

Backup Full

run {
allocate channel t1 type disk;
allocate channel t2 type disk;
allocate channel t3 type disk;
backup as compressed full database include current controlfile tag ‘BKP_BI_FULL’
format ‘/uo1/backup/ora10/full/bkp_full_%d_%t_%s.rman’;
backup current controlfile tag ‘BKP_CF’
format ‘/uo1/backup/ora10/full/bkp_ctl_%d_%t_%s.rman’;
backup spfile tag ‘BKP_SPFILE’
format ‘/uo1/backup/ora10/full/bkp_spfile_%d_%t_%s.rman’;
[b]sql ‘alter system archive log current’;
backup as compressed archivelog all tag ‘BKP_ARCH’
format ‘/uo1/backup/ora10/full/bkp_arch_%d_%t_%s.rman’;[/b]
release channel t1;
release channel t2;
release channel t3;
}

Observações:

Como você configurou o Paralelismo para 4 no RMAN (No catálogo ou controlfile do banco) não precisaria alocar os 3 canais acima de forma manual, a não ser que queira somente 3.

Para o backup FULL, faça os archives junto, para deixar consistente!

Backup Incremental Level 0

run {
allocate channel t1 type disk maxpiecesize = 50G;
sql ‘alter system archive log current’;
backup as compressed backupset incremental level 0 database
include current controlfile
plus archivelog
tag ‘bi_bkp_full’
format ‘/uo1/backup/ora10/full/bkp_l0_diario_%d_%t_%s.rman’;
release channel t1;
}

Esse eu não vejo muitos problemas. Poderia mesclar com outros como esse:

run {
allocate channel t1 type disk maxpiecesize = 50G;
sql ‘alter system archive log current’;
backup as compressed backupset incremental level 1 database
include current controlfile
plus archivelog
tag [/b]’bi_bkp_L1′[b]
format ‘/uo1/backup/ora10/full/bkp_l1_diario_%d_%t_%s.rman’;
release channel t1;
}

run {
allocate channel t1 type disk maxpiecesize = 50G;
sql ‘alter system archive log current’;
backup as compressed backupset incremental level 2 database
include current controlfile
plus archivelog
tag ‘bi_bkp_L2’
format ‘/uo1/backup/ora10/full/bkp_l2_diario_%d_%t_%s.rman’;
release channel t1;
}

Agora, para o backup FULL e INCREMENTAL LEVEL 0, não muda nada, é que o backup INCREMENTAL LEVEL 0 deve ser utilizado como backup base para futuros backups incrementais, 1, 2, 3 e 4.

O padrão do RMAN é FULL, então se eu não dizer nada no comando BACKUP DATABASE, é padrão é FULL. Mas lembre-se que esse FULL não pode ser utilizado com outros incrementais. Pois incrementais nível 1,2,3 e 4 precisa da base do nivel 0.

Abraços,
Rodrigo Almeida[/b]

[vieriParticipante]

Perfeito Rodrigo.

Acho que vou ficar com esse.

Backup Full

run {
allocate channel t1 type disk;
allocate channel t2 type disk;
allocate channel t3 type disk;
backup as compressed full database include current controlfile tag ‘BKP_BI_FULL’
format ‘/uo1/backup/ora10/full/bkp_full_%d_%t_%s.rman’;
backup current controlfile tag ‘BKP_CF’
format ‘/uo1/backup/ora10/full/bkp_ctl_%d_%t_%s.rman’;
backup spfile tag ‘BKP_SPFILE’
format ‘/uo1/backup/ora10/full/bkp_spfile_%d_%t_%s.rman’;
sql ‘alter system archive log current’;
backup as compressed archivelog all tag ‘BKP_ARCH’
format ‘/uo1/backup/ora10/full/bkp_arch_%d_%t_%s.rman’;
release channel t1;
release channel t2;
release channel t3;
}

mas ainda tem + coisa ai no meio.

Esse poderá ser realizado direto para o servidor de bkp
no caso algo do tipo: t:/backora/bi/rman/full/nomearq…
em um ambiente windows posso incluir isso na claúsula format
sem problemas?

Eu só quero manter arquives de 4 dias no server, e indefinidos
no servidor de bkp, pensei em algo do tipo.

SET CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;

Isso me garante isso e remove arquives antigos?
ou to viajando…
não posso remover na mão porque da problema de
crosscheck e tem que usar o tal do uncatalog,
não quero isso.. hehe

abraço e obrigado pela força!!

[vieriParticipante]

Rodrigo,

ajustei para a seguinte forma,
pq as formas acima deu erro de sintaxe.

run {
allocate channel t1 type disk maxpiecesize = 50G;
allocate channel t2 type disk maxpiecesize = 50G;
allocate channel t3 type disk maxpiecesize = 50G;
backup as compressed backupset database include current controlfile tag ‘BKP_BI_FULL_HOT’
format ‘/u03/backup/ora10g/full/bkp_full_%d_%t_%s.rman’;
backup current controlfile tag ‘BKP_CTL’
format ‘/u03/backup/ora10g/full/bkp_ctl_%d_%t_%s.rman’;
backup spfile tag ‘BKP_SPFILE’
format ‘/u03/backup/ora10g/full/bkp_spfile_%d_%t_%s.rman’;
release channel t1;
release channel t2;
release channel t3;
}

CROSSCHECK BACKUP;
RESTORE TABLESPACE SYSTEM VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;
LIST BACKUP OF DATABASE;
REPORT UNRECOVERABLE;
REPORT SCHEMA;
REPORT NEED BACKUP;
REPORT OBSOLETE;
quit

====archives=====

run {
allocate channel ch1 type Disk maxpiecesize = 1000M;
sql “alter system archive log current”;
backup archivelog all filesperset 10
format ‘/u03/backup/ora10g/full/arch/arch_dia_%u_%d_s%s_p%p_t%t’
tag ‘BI_ARCH_BKP’
delete all input;
release channel ch1;
resync catalog;
}

rodei em desenv e ficou ok!!
backupeou 100gb em 10min, e ficou com 250mb comprimido,
acredita nisso? rsrs

Semana que vem vou implementar em produção.

Se eu mapear o diretório do servidor
de backup, com algo do tipo samba, rola sem problemas?
posso passar o caminho na claúsula format?

obrigado são minha últimas dúvidas!! heheh
E devemos ta tirando dúvidas de uma “cabeçada”.

abços!!

[Rodrigo AlmeidaParticipante]

Fala Vieri,

Desculpa a demora para responder, está uma correria danada aqui na empresa!

Seguinte, bacana que o RMAN funcionou perfeitamente, isso é muito bom, RMAN NELES!!!

Sobre utilizar o samba não seria uma boa ideia, o ideal mesmo é criar um NFS entre os servidores para passar o backup de um lado para outro. Entre ambientes linux/windows também é aceito o NFS. Como o samba tem validações de segurança, torna o trafégo mais lento. Tem a opção de usar também o VSFTP e SCP que pode ser uma solução.

Se vai só ter um tipo de backup diário, manda bala! Só dá mais atenção para realizar os backups dos archives, pois como tu está realizando um FULL HOT diário, o que vai salvar a sua alma será os benditos ARCHIVES!!

Então, uma sugestão, para esse tipo de ambiente onde só tem FULL, diminui a janela de backup, para cada 2 ou 4 horas dos archives.

Abraços,
Rodrigo Almeida

[vieriParticipante]

Beleza Rodrigo.

Ja solicitei o mapeamento no servidor de backup
para a galera de infra, se o tempo ficar ruim( a principal motivação é baixar o tempo ) parto para outra estratêgia,
o problema é que não tenhu espaço no disco local para fazer o backup por isso a estratêgia de jogar direto no servidor de backup.

O VSFTP e SCP somente se jogar 1° em disco ?
cofesso que nunca ouvir falar do VSFTP…

Será que essas validaçoes de segurança do samba da para elimina-lás?

O projeto é baixar o tempo do backup para 10hrs pelo menos,
acho que com o compress isso se torna possível,
mas se o samba deixar mto lento vou partir para o NFS.

Com relação aos arquives irei setar agendar na crontab
para executar de 3 em 3 dias
e a claúsula “delete all input;”, remover todos que foram backupeados correto… foi isso que rolou no meu testes…

preciso setar alguma configuration policy para isso?

abraços

[Rodrigo AlmeidaParticipante]

Vieri,

O Retention Policy vai ser definido conforme a sua janela de recuperação, tu pode escolher entre RECOVERY WINDOWS N OF DAYS ou RETENTION REDUNDANCY para N.

Isso é definição mesmo da janela de recuperação.

Sobre o SAMBA, existe alguma opções que retira algumas integridades, porém não sei disser com precisão.

Um ponto que deve levar em consideração, é se fizer o backup direto para o NFSsamba tu não vai ter tanta performance, pois vai depender diretamente da sua rede, ainda mais que não possui uma rede de backup para tal tarefa, vai ter que competir com os usuários!

VSFTP e SCP é para quando o backupset já está pronto em disco e tem que transmitir para outro servidor.

Abraços,
Rodrigo Almeida

[vieriParticipante]

Ai Rodrigão rotina implementada com sucesso utilizando o samba.
Já está em produção!!

resultado:

SEM RMAN:

tamanho do backup : 1tera
tempo de exec: 25hrs

COM RMAN:

tamanho(claúsula as compressed) : 150Gb.
tempo de exec(3 canais): 6hrs e 30minutos.

Fantástico!!!

😀

[Rodrigo AlmeidaParticipante]

Bom Bom….

ótimos tempos, tu pode colocar até mais 2 canais para o backup e diminuir esse tempo sem prejudicar o ambiente!

Bom trabalho Vieri, parabéns!

Abraços,

Rodrigo Almeida

[vieriParticipante]

Obrigado pelos parabéns sem seu apoio não conseguiria realizar isso em curto espaço de tempo e com confiança.
Após esse trabalho me sinto + entrosado com o Rman.

Meu próximo desafio e restaurar esses 1 tera em outro servidor com rman ficará + para frente um pouco…
🙂

vou testar com 5 canais e lhe digo.
Algum motivo especial para o número 5 ? este é o limite de canais do rman?

abraços !

[David SiqueiraParticipante]

Não há um número especifico de Canais Vieri, o numero 5 foi apenas uma sugestão, quanto mais paralelisado for melhor será e mais eficiente e rapido será seu backup, porém não podemos usar esse parametro sem bom senso pois isso comprometeria o Hardware, portanto use 5 canais apenas, e sempre lembrando que isso varia de Hardware pra Hardware e de Banco pra Banco.

Abcs.

David

[vieriParticipante]

Eu aloquei 3 canais, porque o backup é realizado direto para outro servidor via rede.
A paralelismo significa a quantidade de backup piece ele irá “backupeace”,
ao mesmo tempo.

Eu setei cada backuop piece para no máximo 50Gb, acho que isso é importante também…

Da pra fazer mto tunning com rman, só usar a criatividade e conhecer
o ambiente.

Assim que o backup é iniciado 3 arquivos são criados, e são preenchidos pelo rman simultaneamente.

Um valor muito alto poderia gerar gargalos na rede diminuindo o tempo total.

Vou testar isso no fds, para encontrar o valor ideal, acho que não existe receita de bolo! E o maneiro está ai… caso a caso…

😀

[Autor]

Posts