Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Artigo SQL Magazine 72 - Oracle RMAN 11g
O artigo trata das novas funcionalidades da ferramenta de backup da Oracle, o RMAN (Recovery Manager), em sua versão 11g. Trata também de como utilizar algumas das funcionalidades para efetuar backup e recovery em caso de falha do banco de dados.
SQL Magazine 72
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 72
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 72
Oracle
Oracle RMAN 11g
LEAD
De que trata o artigo?
O artigo trata das novas funcionalidades da ferramenta de backup da Oracle, o RMAN (Recovery Manager), em sua versão 11g. Trata também de como utilizar algumas das funcionalidades para efetuar backup e recovery em caso de falha do banco de dados.
Para que serve?
O RMAN (Recovery Manager) é a ferramenta Oracle, parte integrante do banco de dados, que permite a execução de backups do banco de dados Oracle e, principalmente, a recuperação de dados em caso de falha do banco de dados. Este artigo serve para que o leitor tenha conhecimento das principais características da ferramenta e seja capaz de efetuar backups e recuperação em bases de dados de sua responsabilidade.
Em que situação o tema é útil?
Em casos de administradores de bancos de dados que queiram garantir a disponibilidade de dados, executando seus backups com o RMAN 11g. Se você é DBA, um dia você precisará fazer um Recovery. A questão não é SE você vai, e sim QUANDO você vai. Esteja preparado.
A principal responsabilidade de um DBA é a recuperação de dados, mais conhecida pelo termo em inglês Recovery.
Reparem que eu nem disse Backup & Recovery, e sim, apenas a segunda parte. Backup é uma parte do processo de Recovery, é apenas um meio, e não o fim. O objetivo é garantir a recuperabilidade de seus dados. Pense no Recovery, e não no Backup.
O RMAN – Recovery Manager (“Gerenciador de Recuperação”) - é a ferramenta recomendada pela Oracle para executar Backups dos bancos de dados gerenciados por seu principal produto, o Oracle Database, e existe desde a versão 8.0.3.
Não adianta fugir. Se você pretende administrar seriamente um banco de dados Oracle, terá que dominar esta ferramenta. E se pretende usar seriamente RMAN, deverá usar o modo ARCHIVELOG e um Catalog (“Catálogo”), como veremos mais adiante.
Outra razão para utilizar o RMAN é que ele é grátis. Se você pagou pelo Oracle, já pagou pelo RMAN. Para que então ter mais trabalho, ou tentar reinventar a roda?
Se você ainda considera outros métodos de Backup, veja as desvantagens em fazê-los sem o RMAN:
• Manual Cold Backup (“Cópia Manual a Frio”). É o Backup executado copiando-se todos os arquivos do banco de dados para outro local, com a instância desligada, via sistema operacional. Tem a seguinte desvantagem:
o Necessita que a instância seja desligada. Além do tempo de indisponibilidade do banco de dados durante o Backup, quando uma instância é religada, todo seu Caché está limpo, tanto de dados quanto de comandos SQL. Ou seja, todo o trabalho que o Oracle teve para ter uma boa performance de acordo com o uso do banco de dados é destruído.
• User Managed Backups (“Cópias Gerenciadas por Usuário”). É o backup executado copiando-se todos os datafiles (“arquivos de dados”) do banco de dados para outro local, utilizando-se os comandos BEGIN BACKUP e END BACKUP. Possui a seguinte desvantagem:
o Quando uma tablespace é colocada em modo BEGIN BACKUP, o Oracle grava blocos inteiros nos REDO LOGs, ao invés de apenas os vetores alterados. Isto pode fazer com que a geração de REDO durante o backup seja muito maior do que com Backups feitos por RMAN.
• Logical Backup (“Backup Lógico”): é o backup executado utilizado as ferramentas de exportação do Oracle - o exp (todas as versões) ou expdp (versão 10g ou superior). Possui as seguintes desvantagens:
o Não permite recuperação em um ponto do tempo determinado. Você só pode voltar para o momento onde o Backup foi feito;
o Como o processo de Recovery (utilizando as ferramentas de imp / impdp) praticamente reinsere os dados, o tempo será maior do que um Recovery via RMAN. Adicionalmente, ao término do processo de Logical Recovery, os índices são recriados, o que leva mais tempo ainda;
o Integridade: utilizando-se as opções padrão, um Logical Backup pode não ser íntegro, pois, como uma tabela é exportada em seguida da outra, um registro de uma tabela que depende de um registro de outra tabela via Foreign Keys (“Chave Estrangeira”) pode não existir mais, o que invalidará a recriação da Foreign Key ao término do processo de Recovery.
Além disso, os Backups executados com estas opções não podem ser registrados em um Catalog, o que inviabiliza várias funcionalidades, e torna mais difícil a administração de muitos bancos de dados. Além disso, obviamente, todas as funcionalidades do RMAN não poderão ser utilizadas.
O Catalog, em especial, é uma funcionalidade importante do RMAN. Várias funcionalidades do RMAN, como Stored Scripts, só podem ser utilizadas com um Catalog, como demonstraremos a seguir. Um banco de dados Oracle de produção deve utilizar um Catalog para registro de seus Backups.
Outro ponto importante a considerar é que você deve treinar os procedimentos de Recovery. Em situações de estresse, tendemos naturalmente a não considerar as opções com as quais não estamos familiarizados. E uma situação onde um Recovery é necessário geralmente é uma situação de estresse.
Se você é DBA, um dia você precisará fazer um Recovery. A questão não é SE você vai, e sim QUANDO você vai. Esteja preparado.
Mas reconheço que o RMAN não é uma ferramenta muito amigável, assim como o Oracle não é um banco muito amigável aos iniciantes. Mas isto está mudando.
Na versão 11g, foi introduzido o Data Recovery Advisor, que como outros Advisors que o Oracle já tem, procura auxiliar o DBA menos experiente a executar tarefas complexas, como um Recovery. Iremos, neste artigo, configurar o RMAN para executar Backups, e depois iremos simular uma situação onde um Recovery é necessário, e deixar o Data Recovery Advisor fazer este Recovery."
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Oracle RMAN 11g
LEAD
De que trata o artigo?
O artigo trata das novas funcionalidades da ferramenta de backup da Oracle, o RMAN (Recovery Manager), em sua versão 11g. Trata também de como utilizar algumas das funcionalidades para efetuar backup e recovery em caso de falha do banco de dados.
Para que serve?
O RMAN (Recovery Manager) é a ferramenta Oracle, parte integrante do banco de dados, que permite a execução de backups do banco de dados Oracle e, principalmente, a recuperação de dados em caso de falha do banco de dados. Este artigo serve para que o leitor tenha conhecimento das principais características da ferramenta e seja capaz de efetuar backups e recuperação em bases de dados de sua responsabilidade.
Em que situação o tema é útil?
Em casos de administradores de bancos de dados que queiram garantir a disponibilidade de dados, executando seus backups com o RMAN 11g. Se você é DBA, um dia você precisará fazer um Recovery. A questão não é SE você vai, e sim QUANDO você vai. Esteja preparado.
A principal responsabilidade de um DBA é a recuperação de dados, mais conhecida pelo termo em inglês Recovery.
Reparem que eu nem disse Backup & Recovery, e sim, apenas a segunda parte. Backup é uma parte do processo de Recovery, é apenas um meio, e não o fim. O objetivo é garantir a recuperabilidade de seus dados. Pense no Recovery, e não no Backup.
O RMAN – Recovery Manager (“Gerenciador de Recuperação”) - é a ferramenta recomendada pela Oracle para executar Backups dos bancos de dados gerenciados por seu principal produto, o Oracle Database, e existe desde a versão 8.0.3.
Não adianta fugir. Se você pretende administrar seriamente um banco de dados Oracle, terá que dominar esta ferramenta. E se pretende usar seriamente RMAN, deverá usar o modo ARCHIVELOG e um Catalog (“Catálogo”), como veremos mais adiante.
Outra razão para utilizar o RMAN é que ele é grátis. Se você pagou pelo Oracle, já pagou pelo RMAN. Para que então ter mais trabalho, ou tentar reinventar a roda?
Se você ainda considera outros métodos de Backup, veja as desvantagens em fazê-los sem o RMAN:
• Manual Cold Backup (“Cópia Manual a Frio”). É o Backup executado copiando-se todos os arquivos do banco de dados para outro local, com a instância desligada, via sistema operacional. Tem a seguinte desvantagem:
o Necessita que a instância seja desligada. Além do tempo de indisponibilidade do banco de dados durante o Backup, quando uma instância é religada, todo seu Caché está limpo, tanto de dados quanto de comandos SQL. Ou seja, todo o trabalho que o Oracle teve para ter uma boa performance de acordo com o uso do banco de dados é destruído.
• User Managed Backups (“Cópias Gerenciadas por Usuário”). É o backup executado copiando-se todos os datafiles (“arquivos de dados”) do banco de dados para outro local, utilizando-se os comandos BEGIN BACKUP e END BACKUP. Possui a seguinte desvantagem:
o Quando uma tablespace é colocada em modo BEGIN BACKUP, o Oracle grava blocos inteiros nos REDO LOGs, ao invés de apenas os vetores alterados. Isto pode fazer com que a geração de REDO durante o backup seja muito maior do que com Backups feitos por RMAN.
• Logical Backup (“Backup Lógico”): é o backup executado utilizado as ferramentas de exportação do Oracle - o exp (todas as versões) ou expdp (versão 10g ou superior). Possui as seguintes desvantagens:
o Não permite recuperação em um ponto do tempo determinado. Você só pode voltar para o momento onde o Backup foi feito;
o Como o processo de Recovery (utilizando as ferramentas de imp / impdp) praticamente reinsere os dados, o tempo será maior do que um Recovery via RMAN. Adicionalmente, ao término do processo de Logical Recovery, os índices são recriados, o que leva mais tempo ainda;
o Integridade: utilizando-se as opções padrão, um Logical Backup pode não ser íntegro, pois, como uma tabela é exportada em seguida da outra, um registro de uma tabela que depende de um registro de outra tabela via Foreign Keys (“Chave Estrangeira”) pode não existir mais, o que invalidará a recriação da Foreign Key ao término do processo de Recovery.
Além disso, os Backups executados com estas opções não podem ser registrados em um Catalog, o que inviabiliza várias funcionalidades, e torna mais difícil a administração de muitos bancos de dados. Além disso, obviamente, todas as funcionalidades do RMAN não poderão ser utilizadas.
O Catalog, em especial, é uma funcionalidade importante do RMAN. Várias funcionalidades do RMAN, como Stored Scripts, só podem ser utilizadas com um Catalog, como demonstraremos a seguir. Um banco de dados Oracle de produção deve utilizar um Catalog para registro de seus Backups.
Outro ponto importante a considerar é que você deve treinar os procedimentos de Recovery. Em situações de estresse, tendemos naturalmente a não considerar as opções com as quais não estamos familiarizados. E uma situação onde um Recovery é necessário geralmente é uma situação de estresse.
Se você é DBA, um dia você precisará fazer um Recovery. A questão não é SE você vai, e sim QUANDO você vai. Esteja preparado.
Mas reconheço que o RMAN não é uma ferramenta muito amigável, assim como o Oracle não é um banco muito amigável aos iniciantes. Mas isto está mudando.
Na versão 11g, foi introduzido o Data Recovery Advisor, que como outros Advisors que o Oracle já tem, procura auxiliar o DBA menos experiente a executar tarefas complexas, como um Recovery. Iremos, neste artigo, configurar o RMAN para executar Backups, e depois iremos simular uma situação onde um Recovery é necessário, e deixar o Data Recovery Advisor fazer este Recovery."
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
3 COMENTÁRIOS
Hiran Horta
Bom dia a todos.
Este artigo é muito bom!
Serve como ótima base de conhecimentos a todos os colegas DBAs.
Ricardo, parabéns pelo artigo e pela objetividade posta. Sou DBA Oracle a 15 anos e é o primeiro artigo que leio objetivo, imparcial, presciso e de apoio que considero bom.
Abraços
Hiran Horta.
[há +1 ano] -
Responder
Renato F Ferreira
Falam pra pensar em Recovery, porém só explicaram como faz o backup, o recovery ficou muito mal explicado.
Se meu servidor oracle dá pau físico, tenho que subir o backup em outra máquina, como faço ? Não está explicado.
Se uma atualização do banco de dados deu erro, como faço para voltar o banco ao momento antes da atualização ? Não está explicado.
Se meu servidor oracle dá pau físico, tenho que subir o backup em outra máquina, como faço ? Não está explicado.
Se uma atualização do banco de dados deu erro, como faço para voltar o banco ao momento antes da atualização ? Não está explicado.
[há +1 mês] -
Responder
[autor]
Ricardo Portilho Proni
Você está certo. O Recover foi abordado muito na forma filosófica, e pouco na prática. Planejo escrever um artigo apenas sobre técnicas de Restore & Recover.
[há +1 mês] -
Responder
Artigo SQL Magazine 52 - Estudos de Caso de Projeto de Bancos de Dados para Contas a Pagar e Receber
Artigo da SQL Magazine 26 - SQL Server 2000 fail-over clustering Parte II: Instalação e Configuração
Artigo SQL Magazine 23 - Influenciando o otimizador de consulta baseado em custo do Oracle - Parte 3
Artigo SQL Magazine 20 - Influenciando o otimizador de consulta baseadoem custo do Oracle - Parte II
Você está em:
canal SQL
Publicidade
Ricardo Portilho Proni
Space do autor
Com 20 anos de experiência profissional, Ricardo Portilho Proni é Oracle ACE e já trabalhou em grande parte dos maiores bancos de dados Oracle e MySQL do Brasil. É certificado em Oracle, MySQL, SQL Server, DB2, Sybase e WebSphere. Consultor e Instrutor da Nerv Informática Ltda (http://nervinformatic...
Space do autor
1
0
