Eliandro, A idéia não é parar o banco (para fazer um backup consistente).... a idéia é você copiar o backup realizado pelo RMAN e ele sim ser duplicado para um local que o expire do rman não os apague.
Quanto a licenciamento pode ficar tranquilo você aramzenar seu backup em diferente locais não aumenta em nada o que você já supostamente deveria estar pagando. Agora se você está utilizando o Dataguard ai sim precisa licenciar o segundo servidor além é claro de ter o licenciamento do primário como Enterprise. Essa questão do licenciamento do segundo servidor é bem polemica e no último Oracle Open World finalmente consegue uma formalização que precisa sim licenciar, por mais que algumas pessoas justifique que estudos revelaram que esse ambiente só fica OPEN por 10 dias ao ano essa informação não resulta em não licenciar o seu segundo servidor e dobrar o custo de licenças enterprise não costuma ser muito barato :) ... Esse é o preço da Alta Disponibilidade que todos adoram falar, mas poucos teriam coragem de pagar... Atenciosamente, Caio Spadafora. http://0011brothers.blogspot.com/ --- Em qua, 10/6/09, Eliandro Jakubski <elian...@itaipu.gov.br> escreveu: De: Eliandro Jakubski <elian...@itaipu.gov.br> Assunto: Re: [oracle_br] RMAN e políticas de bkp Para: oracle_br@yahoogrupos.com.br Data: Quarta-feira, 10 de Junho de 2009, 12:17 Concordo que para as políticas semanal e anual eu posso resolver da seguinte forma (sem rman): - Parada consistente do banco; - Cópia imagem do servidor Oracle (binários do oracle + dados + SO); Obs.: Só não sei se a Oracle não irá querer cobrar pelo binário que do banco que estará em fita (há, há)! Isso me atende perfeitamente! Só estou analisando as outras opções associadas com o bkp dos dados! De: Caio Spadafora <caiospadafora@ yahoo.com. br> Para: oracle...@yahoogrup os.com.br Data: 10/06/2009 11:49 Assunto: Re: [oracle_br] RMAN e políticas de bkp Eliandro, Alterar o DBID é facil o problema é fazer o Dataguard conseguir replicar os redos e principalmente aplicar com DBIDs diferentes, talvez isso seja possível somente com SQL Apply (standby lógico), que não é tão recomendado para backup. Caso queira se aventurar nesse teste o utilitário que altera o DBID (acho que não vai funcionar a replicação após isso) é o DBNEWID ( http://download- west.oracle. com/docs/ cd/B10501_ 01/server. 920/a96652/ ch14.htm ). Você não pode contornar isso por fora do RMAN como eu sugeri? Atenciosamente, Caio Spadafora. http://0011brothers .blogspot. com/ --- Em qua, 10/6/09, Eliandro Jakubski <elian...@itaipu. gov.br> escreveu: De: Eliandro Jakubski <elian...@itaipu. gov.br> Assunto: Re: [oracle_br] RMAN e políticas de bkp Para: oracle...@yahoogrup os.com.br Data: Quarta-feira, 10 de Junho de 2009, 11:31 Sim, Sim o bkp no standby será com o banco montado! Se o banco standby é uma réplica do banco primário como eu poderia ter outro DBID para ele (de forma a ele ter um registro diferente no catálogo do rman)? Eliandro. De: Caio Spadafora <caiospadafora@ yahoo.com. br> Para: oracle...@yahoogrup os.com.br Data: 10/06/2009 11:24 Assunto: Re: [oracle_br] RMAN e políticas de bkp Eliandro, Um dos principais objetivos do standby além do espelhamento é transferir a política de backup para ele, imagino que ele não fique offline e sim mounted, você pode sim utilizá-lo sem problema, porém se for um único catálogo para os dois bancos os dois backups, até onde imagino, vão ser entendidos por ambos os bancos (mesmo DBID). Um outro ponto é que você fazendo backup pelo standby ou não, a necessidade de archives é a mesma. Você hoje utiliza o parametro DELETE INPUT nos backups de archive? Se você precisa dessas retenções semanais e anuais (haja espaço) sugiro que você contorne isso por fora do RMAN, ou seja, agende na cron (ou em alguma ferramenta de backup que sua empresa possui: TSM, NetBackup, etc) uma cópia dos backups que atendam essas diferentes retenções para outro destino e mantenha eles fora do catálogo. Caso um dia você precise restaurar esses backups você os recataloga e pronto. Não sei se era esse o seu ponto, se não for, por favor, me corrija. Atenciosamente, Caio Spadafora. http://0011brothers .blogspot. com/ --- Em qua, 10/6/09, Eliandro Jakubski <elian...@itaipu. gov.br> escreveu: De: Eliandro Jakubski <elian...@itaipu. gov.br> Assunto: [oracle_br] RMAN e políticas de bkp Para: oracle...@yahoogrup os.com.br Data: Quarta-feira, 10 de Junho de 2009, 7:38 Pessoal, tenho uma base 10.2.0.4 sobre AIX com requisitos de 24x7. A empresa estabelece oficialmente 3 políticas de bkp: Diária: retenção de 15 dias; Semanal: retenção de 72 semanas e Anual: Retenção por 5 anos. De cara, no rman, tenho uma única "recovery window". Para implementar as políticas pensei em manter uma recovery window de 15 dias (política diária) e utilizar o comando "keep until time" do rman para reter os bkp´s de forma a atender as políticas semanal e anual. O problema com o comando "keep until time" do rman é que ele é uma M qdo. utilizado com o banco online. Para manter os bkp´s consistentes ele passa a não considerar obsoletos todos os archives posteriores ao bkp com keep. Me parece que isso foi resolvido no 11 (bkp´s self contidos). Dado o problema com o keep, pensei em utilizar o comando keep no banco standby (com banco offline). Minhas dúvidas: - Qdo faço um bkp no standby (o DBID do banco standby é o mesmo do DBID do primário!) utilizando catálogo do rman os bkps passam a estar "visíveis" no banco primário (via catálogo), tal comportamento pode gerar algum inconveniente? - Alguém utiliza a máquina standby para realizar bkp´s rman? Eliandro. [As partes desta mensagem que não continham texto foram removidas] Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbusca dos.yahoo. com [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbusca dos.yahoo. com [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com [As partes desta mensagem que não continham texto foram removidas]
