Marcelo, a opção que eu me referia é o backup backupset, conforme informado pelo chiappa e presente aqui: http://docs.oracle.com/cd/B19306_01/backup.102/b14191/rcmbackp.htm#i1006269
Acho que meu e-mail anterior ficou um pouco confuso, por causa da palavra simultaneamente... hehehe :) Att,/Regards, Vitor Jr. Infraestrutura / Infrastructure Team Oracle 11g DBA Certified Professional - OCP Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid Infrastructure Administrator - OCE Oracle Database 11g Performance Tuning Certified Expert - OCE Oracle Exadata 11g Certified Implementation Specialist Oracle Certified Associate, MySQL 5 mail, gtalk e msn: vitorj...@gmail.com http://certificacaobd.com.br/ skype: vjunior1981 https://mybizcard.co/vitor.jr.385628 Em 1 de abril de 2014 15:22, Marcelo Santino <e...@marcelosantino.com.br>escreveu: > > > @Vitor, > > Eu cheguei a procurar sobre isso, mas segundo a > documentação<http://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmcncpt.htm#BRADV107>, > eu não consigo escrever em fita e disco ao mesmo tempo e esse precisa > necessariamente ser o meu cenário. Foi inclusive a mesma referência que o > Chiappa mandou sobre o assunto... Appesar do RMAN possuir esse recurso, não > se enquadra no meu cenário. > > @Ederson, > > Choveu um pouquinho no molhado sim (rs...) mas não por exagero, realmente > todo cuidado é pouco quando falamos nesse assunto. > Na verdade, são 3 servidores (exatamente iguais) segurando todas as bases > e caso um falhe, ainda tenho 2 onde posso subir. Os 3 possuem comunicação > com os mesmos dispositivos externos e já fiz validação de restore do backup > da fita de um no outro. Essa estratégia a principio está bem definida. > > Além disso, das 3 bases mais críticas dentro desse parque, temos um > standby pobre em uma VM que já foi validada a virada pra ela em simulação e > inclusive, recentemente precisamos virar uma das bases pra lá, que rodou > por um sábado inteiro sem problemas. > > A questão é que justamente pelo ultimo incidente ue tivemos onde eu perdi > o servidor mas não os discos, teria sido muito mais rápido eu retornar o > backup do proprio disco do que da fita. Embora não tenha significado > indisponibilidade, gostaria de contar com essa possibilidade pra aumentar > as chances de uma janela menor. > > O mundo perfeito seria escrever ao mesmo tempo pra fita e pra disco, mas > pelo que entendi, não é possível. > > @Chiappa, > Acho que as minhas opção estão bem resumidas mesmo. Sinceramente não posso > escrever em disco e depois copiar/mover pra fita, pois a política de > segurança não me permite. No relatório apresentado para a auditoria é > necessário que haja um backup gerado diretamente para um dispositivo > externo de backup. Backup para um NAS/afins não se enquadra nessa opção! > > Achei a opção 2 bem interessante, honestamente sequer pensei que seria > possível isso, mas pelo que entendi bem, eu estaria fazendo um backup > (cópia) do backup, certo? Acho que é justamente o que eu quero (ja que não > é possível cuspir diretamente pros 2 canais ao mesmo tempo). Assim eu jogo > o meu backup pra fita como manda o figurino e extraio uma cópia dele. É > meio redundante e vai alocar mais tempo da fita, mas pelo menos eu atendo à > especificação do ambiente e mantenho uma cópia local. > > Como eu disse, o backup roda normalmente durante a madrugada, eu tenho > janela suficiente pra essa atividade. Então quero aproveitar essa > possibilidade pra adiantar o meu lado, caso precise. > > Valeu pela ajuda galera, vou seguir esse plano e qualquer coisa posto por > aqui... > > > > > > > *Marcelo Santino* > DBA SQL Server / Oracle > www.bau-de-dev.com <http://www-bau-de-dev.com> > +55 21 98206-9930 > > <http://www.facebook.com/CelaoRJ> <http://br.linkedin.com/in/msantino> > > <http://twitter.com/#!/msantino> > > > > > 2014-04-01 11:15 GMT-03:00 <jlchia...@yahoo.com.br>: > >> >> >> Tudo jóia ? Então, ao que entendi o que vc quer é duplexar os arquivos de >> backup, mas em devices diferentes (disco e fita, no caso) - o procedimento >> built-in para se obter isso já na hora que se faz o backup é a opção COPIES >> do comando BACKUP (ou pode setar via SET/CONFIGURE), mas o documento >> correspondente (manual "Oracle(R) Database Backup and Recovery Reference 11g >> Release 2 (11.2)" no item sobre o comando BACKUP nos diz : >> >> " >> COPIES integer Sets the number of identical backups (1 - 4) that RMAN >> creates. The default value is 1. >> >> You can use multiple format strings to specify different names and >> locations for the copies. Example 2-22 illustrates a duplexed backup to >> different locations on disk. >> >> RMAN can duplex backups to either disk or tape, but *** cannot duplex >> backups to tape and disk simultaneously *** . >> >> You can specify duplexing in multiple commands. >> " >> >> ou seja, com a opção específica de duplex vc não consegue o que quer.... >> Vc teria as seguintes opções, então : >> >> 1. realmente passar a fazer o backup em disco, e posteriormente copiar >> (não mover, copiar) os arquivos do backup para fita, ** por fora do RMAN >> **, usando a opção apropriada do teu software de backup&gerenciamento de >> fita : isso vai te dar a vantagem da performance (já que backup para disco >> é via de regra mais rápido que para fita) E a vantagem de liberar a fita >> durante a janela de backup (essa cópia dos arqs de backup pode Inclusive >> ser feita durante o dia, período em que normalmente não há backups)... As >> desvantagens são : vc vai ter que mudar as suas rotinas de backup atuais E >> o gerenciamento do conteúdo da fita vai ser feito por fora do RMAN, o RMAN >> nem imagina que existe essa "cópia do backup" em fita... >> >> ou >> >> 2. para vc obter o mesmo efeito que 1. acima mas com algum >> controle/registro por parte do RMAN, vc pode usar o comando BACKUP >> BACKUPSET (não confundir com o BACKUP databaseouqueobjetofor AS BACKUPSET, >> que vc usa para backupear o objeto/database em formato de backupset) : com >> esse comando BACKUP BACKUPSET (sem o AS) vc está mandando o RMAN fazer uma >> cópia (em fita, presumivelmente) do teu backupset... No mesmo manual acima >> citado, veja o item "Backups of Backup Sets" >> >> ou >> >> 3. se for imperativo vc manter o backup "principal" indo para a fita, a >> opção seria vc trazer da fita os arquivos do backup recém-feito : vc até >> poderia usar as opções de restore do RMAN só trocando o local de destino e >> o id do database, mas imho o mais simples seria fazer por fora do RMAN, ie, >> apenas lançar mão dos comandos de leitura e gravação dos arquivos em fita >> do teu gerenciador de fitas/backups (Tivoli, NetBackup, seja qual for) e >> ler da fita e gravar em disco os arquivos correspondentes ao último backup >> - em caso de necessidade depois vc cataloga esses arqs em disco para o RMAN >> tomar conhecimento deles.... >> A vantagem é que vc está testando o que foi gravado na fita, em tese >> pegando erros de gravação pouco tempo depois, e a desvantagem principal é >> que vc VAI estar usando o hardware de fita por muito mais tempo, facilmente >> isso pode interferir no schedule de backup/restore de Outros ambientes que >> queiram usar o mesmo hardware... >> >> ou >> >> 4. manda um backup que não seja as backupset (um image/as copy, como vc >> sugere) para disco : faz muuuuito tempo que eu não faço isso, mas iirc sim, >> um backup do tipo "cópia integral do database" não interferiria no >> sequenciamento dos seus backups as backupset.... Testa aí no seu ambiente >> de testes/homologação mas afaik é isso mesmo >> >> Blz ? De recomendações, se eu fosse vc ia de 1 ou 2, mas em tese qquer >> uma das opções funcionaria : analise todas e veja qual a melhor pro seu >> caso... >> >> []s >> >> Chiappa >> > > >
