Agora, vamos discutir um pouco sobre os tipos de backups citados na Parte I (Artigo anterior).
Backup Frio (Cold Backup) - backup realizado com o banco de dados offline, ou seja consistente. O backup cold pode ser feito de modo automatizado através do RMAN (Recovery Manager) ou através de scripts shell (Linux/Unix) ou batch (Windows), onde para o formato manual do backup, pode envolver a cópia até mesmo dos arquivos de redo log, no RMAN não é necessário. Interessante ter um backup frio na sua estratégia de backup.
Backup Quente (Hot backup) - backup realizado com o banco de dados online, ou seja inconsistente. O backup HOT é um dos principais tipos de backup realizados nos ambientes de produção, pois não é necessário a parada do banco de dados, quando está em modo ARCHIVELOG, porém, uma estratégia de backup HOT pode envolver a utilização de níveis de backups incrementais, como:
* Backup incremental nível 0, ou backup base;
* Backup incremental nível 1, 2, 3 e 4.
Ao colocar esses níveis de backup na sua estratégia, irá ganhar performance, redução de volumetria de backup gerado e aumentar o nível de disponibilidade dos dados, dando mais eficiência à recuperação. Acho que é a opção mínima de backup para o ambiente de produção.
Backup por tablespace - backup realizado para uma determinada tablespace, tendo como opção até mesmo a seleção dos datafiles que poderão ser copiados, pode ser feito manualmente e automaticamente, mas em alguns banco de dados existem tablespaces que armazenam as principais tabelas da aplicação, em que pode forçar uma parada crítica da aplicação. Então, vem a pergunta valendo 1 milhão: Se eu peder uma tablespace com tabelas de alta criticidade à aplicação, tenho que voltar o meu banco de dados por completo?
A resposta é simples: se traçou um bom planejamento e tem recursos de hardware disponível, poderá aplicar uma técnica apenas de recuperação da tablespace e seus respectivos datafiles, chamada TSPITR (Tablespace Point-in-Time Recovery), que pode ser realizado manualmente ou automatizado com RMAN, onde não é necessário voltar seu backup por completo, porém, é necessário uma máquina auxiliar nessa atividade ou espaço em disco suficiente na própria máquina que ocorreu o problema, com isso, podemos recuperar partes do banco de dados de forma completa e deixar a aplicação operante.
Backup por control file - é o bakcup de um dos principais arquivos do banco de dados, onde armazena todas as informações do banco de dados com checkpoint, valor de scn, origem dos datafiles, tablespaces, nome do banco de dados, backupsets e etc. Esse backup pode ser feito manualmente ou automático pelo RMAN ou até mesmo por um trace diretamente do SQL*PLUS, usando o comando ALTER DATABASE BACKUP CONTROLFILE TO TRACE.
Export do banco de dados - é uma espécie de backup lógico, ou seja, poderá realizar um backup completo ou por usuário do banco de dados, porém, muitos se enganam quando deixam apenas um EXPORT, ou apenas DMP (Dump) como é conhecido no mercado, pois o EXPORT não garante a segurança total dos dados e com isso poderá ter perda de dados, o que geralmente para uma empresa não é muito bom. Basta analisar um simples exemplo prático.
Imagine que tenho um banco de dados que é atualizado todos os dias, com INSERT/DELETE/UPDATES diários, um bom e velho OLTP (Online Transaction Processs), e na minha estratégia de backup tenha apenas um Export (ou DMP, como preferir) realizado sempre às 07:00Hs da manhã.
Em uma bela sexta-feira às 17:45Hs da tarde, o servidor que hospeda esse banco de dados teve problemas nos discos internos, perdeu-se archived logs do dia e um maravilhoso "crash" na base. Sua recuperação ficou impossível, o que você tem na mão para salvar o mundo? Apenas um DMPzinho das 07:00Hs da manhã, e o que aconteceu com todas as movimentações das 07:00Hs até as 17:45Hs? Vão sumir? Você não tem archived logs e a base está totalmente inconsistente para recuperação. Resultado final: muito café e cigarros para falar esse cenário com o seu gerente.
Isso é apenas um cenário que ocorre em muitas empresas, onde as Leis de Murphy podem ocorrer, e quando ocorre sua reputação pode estar em jogo. E pior, existem muitos ambientes que estão com esse cenário atualmente.
Arquivos de carga - é considerado backup, principalmente para ambiente de Data WareHouse onde existe uma alta volumetria de dados e os bancos de dados não trabalham em ARCHIVELOG, pois, como você poderia recuperar os dados que foram apagados acidentalmente nos dias 20 e 21 de uma tabela de FATO ou de alguma dimensão importante do seu DW? Com Mágica? Export poderia resolver o problema também, mas trazer um export FULL de um DW não seria muito legal (esperar cansa!), e nesse caso, como estamos falando de apenas 2 dias, por que não os arquivos de carga desses dias! Usando o mesmo processo de ETL poderia refazer a carga e completar a tabela novamente com seus respectivos dados, em bem menos tempo.
Cópia fria de um banco de dados - é uma opção muito interessante para implementar na estratégia de backup da empresa onde tem bancos de dados praticamente abertos ao público, ou seja, até o porteiro sabe a senha do owner da aplicação e o estagiário treina seus primeiros comandos DML diretamente na base de produção, porque somente a produção tem uma volumetria para ele testar o tempo e a eficiência do seu DELETE.
E quando estamos falando de cópia fria, não precisa ser as práticas do "Old School", baixa o banco de dados e CTRL+C e CTRL+V em todos os arquivos e copia para outra máquina. É uma solução também dependendo do ambiente, mas por que não optar por um DUPLICATE DATABASE, usar um Data Guard (Lógico ou Físico), Stand-by database, ou um backup online na produção e restore em outra máquina, com o RMAN, isso é possível até entre diferentes plataformas, de um Linux para Windows. Olha que maravilha! Desde jeito você consegue uma imagem da sua produção e consultar essa imagem para reparar os "ensinamentos" do estagiário na produção! Recomendação: Depois ensina o controle ROLLBACK! rs.
Cópia dos objetos do banco de dados, esse é um ponto interessante também, principalmente quando sua empresa não tem definição de ambientes, como desenvolvimento, homologação e produção. Poucos DBAs se atentam nisso, mas quando é necessário voltar uma procedure que foi alterada em produção e essa alteração não ajudou em nada ou pior, só complicou as coisas! Qual a sua estratégia para voltar isso? Montar um owner em alguma base de teste ou na sua própria máquina e realizar um IMPORT do owner da aplicação sem registros e posteriormente pegar o DDL da procedure? Pegar os DDL do desenvolvimento ou homologação? Ou mandar o desenvolvedor se virar? Quais as alternativas!
Para resolver esse simples probleminha, basta começar a realizar um backup lógico dos objetos do banco de dados, pode usar as próprias views do dicionário de dados do Oracle, como dba_source, dba_triggers, dba_views, dba_mviews e etc, usar o pacote DBMS_METADATA, gerar um DDL script com o Export ou até mesmo para os adeptos de programas gráficos como PL/SQL Developer, SQL Developer e TOAD gerar um "scriptão" a partir deles!
Nessa simples solução, que pode economizar tempo, menos estresse e agilizar o objeto correto ao banco de dados, vai gastar apenas tempo para preparar os scripts e, posteriormente, realizar os agendamentos necessários e mandar para FITA, eles podem gerados em arquivos com os nomes e tipos dos objetos, um script completo do owner da aplicação com a data do backup e etc. Fica a gosto do cliente!
Percebeu que existem diversos tipos, formas, tamanhos, técnicas, soluções e práticas de backup, uma boa estratégia de backup varia muito conforme o ambiente e os recursos que a empresa oferece, e também as estratégias que o DBA irá implementar na empresa. O banco de dados Oracle oferece para você um leque de opções, basta saber aplicar essas opções. É igual ao antigo slogan do um ótimo produto da NESTLE.
Existem 1001 maneiras de preparar sua Estratégia de backup, invente a sua!
Extractos do texto retirados do site imaster
Backup Frio (Cold Backup) - backup realizado com o banco de dados offline, ou seja consistente. O backup cold pode ser feito de modo automatizado através do RMAN (Recovery Manager) ou através de scripts shell (Linux/Unix) ou batch (Windows), onde para o formato manual do backup, pode envolver a cópia até mesmo dos arquivos de redo log, no RMAN não é necessário. Interessante ter um backup frio na sua estratégia de backup.
Backup Quente (Hot backup) - backup realizado com o banco de dados online, ou seja inconsistente. O backup HOT é um dos principais tipos de backup realizados nos ambientes de produção, pois não é necessário a parada do banco de dados, quando está em modo ARCHIVELOG, porém, uma estratégia de backup HOT pode envolver a utilização de níveis de backups incrementais, como:
* Backup incremental nível 0, ou backup base;
* Backup incremental nível 1, 2, 3 e 4.
Ao colocar esses níveis de backup na sua estratégia, irá ganhar performance, redução de volumetria de backup gerado e aumentar o nível de disponibilidade dos dados, dando mais eficiência à recuperação. Acho que é a opção mínima de backup para o ambiente de produção.
Backup por tablespace - backup realizado para uma determinada tablespace, tendo como opção até mesmo a seleção dos datafiles que poderão ser copiados, pode ser feito manualmente e automaticamente, mas em alguns banco de dados existem tablespaces que armazenam as principais tabelas da aplicação, em que pode forçar uma parada crítica da aplicação. Então, vem a pergunta valendo 1 milhão: Se eu peder uma tablespace com tabelas de alta criticidade à aplicação, tenho que voltar o meu banco de dados por completo?
A resposta é simples: se traçou um bom planejamento e tem recursos de hardware disponível, poderá aplicar uma técnica apenas de recuperação da tablespace e seus respectivos datafiles, chamada TSPITR (Tablespace Point-in-Time Recovery), que pode ser realizado manualmente ou automatizado com RMAN, onde não é necessário voltar seu backup por completo, porém, é necessário uma máquina auxiliar nessa atividade ou espaço em disco suficiente na própria máquina que ocorreu o problema, com isso, podemos recuperar partes do banco de dados de forma completa e deixar a aplicação operante.
Backup por control file - é o bakcup de um dos principais arquivos do banco de dados, onde armazena todas as informações do banco de dados com checkpoint, valor de scn, origem dos datafiles, tablespaces, nome do banco de dados, backupsets e etc. Esse backup pode ser feito manualmente ou automático pelo RMAN ou até mesmo por um trace diretamente do SQL*PLUS, usando o comando ALTER DATABASE BACKUP CONTROLFILE TO TRACE.
Export do banco de dados - é uma espécie de backup lógico, ou seja, poderá realizar um backup completo ou por usuário do banco de dados, porém, muitos se enganam quando deixam apenas um EXPORT, ou apenas DMP (Dump) como é conhecido no mercado, pois o EXPORT não garante a segurança total dos dados e com isso poderá ter perda de dados, o que geralmente para uma empresa não é muito bom. Basta analisar um simples exemplo prático.
Imagine que tenho um banco de dados que é atualizado todos os dias, com INSERT/DELETE/UPDATES diários, um bom e velho OLTP (Online Transaction Processs), e na minha estratégia de backup tenha apenas um Export (ou DMP, como preferir) realizado sempre às 07:00Hs da manhã.
Em uma bela sexta-feira às 17:45Hs da tarde, o servidor que hospeda esse banco de dados teve problemas nos discos internos, perdeu-se archived logs do dia e um maravilhoso "crash" na base. Sua recuperação ficou impossível, o que você tem na mão para salvar o mundo? Apenas um DMPzinho das 07:00Hs da manhã, e o que aconteceu com todas as movimentações das 07:00Hs até as 17:45Hs? Vão sumir? Você não tem archived logs e a base está totalmente inconsistente para recuperação. Resultado final: muito café e cigarros para falar esse cenário com o seu gerente.
Isso é apenas um cenário que ocorre em muitas empresas, onde as Leis de Murphy podem ocorrer, e quando ocorre sua reputação pode estar em jogo. E pior, existem muitos ambientes que estão com esse cenário atualmente.
Arquivos de carga - é considerado backup, principalmente para ambiente de Data WareHouse onde existe uma alta volumetria de dados e os bancos de dados não trabalham em ARCHIVELOG, pois, como você poderia recuperar os dados que foram apagados acidentalmente nos dias 20 e 21 de uma tabela de FATO ou de alguma dimensão importante do seu DW? Com Mágica? Export poderia resolver o problema também, mas trazer um export FULL de um DW não seria muito legal (esperar cansa!), e nesse caso, como estamos falando de apenas 2 dias, por que não os arquivos de carga desses dias! Usando o mesmo processo de ETL poderia refazer a carga e completar a tabela novamente com seus respectivos dados, em bem menos tempo.
Cópia fria de um banco de dados - é uma opção muito interessante para implementar na estratégia de backup da empresa onde tem bancos de dados praticamente abertos ao público, ou seja, até o porteiro sabe a senha do owner da aplicação e o estagiário treina seus primeiros comandos DML diretamente na base de produção, porque somente a produção tem uma volumetria para ele testar o tempo e a eficiência do seu DELETE.
E quando estamos falando de cópia fria, não precisa ser as práticas do "Old School", baixa o banco de dados e CTRL+C e CTRL+V em todos os arquivos e copia para outra máquina. É uma solução também dependendo do ambiente, mas por que não optar por um DUPLICATE DATABASE, usar um Data Guard (Lógico ou Físico), Stand-by database, ou um backup online na produção e restore em outra máquina, com o RMAN, isso é possível até entre diferentes plataformas, de um Linux para Windows. Olha que maravilha! Desde jeito você consegue uma imagem da sua produção e consultar essa imagem para reparar os "ensinamentos" do estagiário na produção! Recomendação: Depois ensina o controle ROLLBACK! rs.
Cópia dos objetos do banco de dados, esse é um ponto interessante também, principalmente quando sua empresa não tem definição de ambientes, como desenvolvimento, homologação e produção. Poucos DBAs se atentam nisso, mas quando é necessário voltar uma procedure que foi alterada em produção e essa alteração não ajudou em nada ou pior, só complicou as coisas! Qual a sua estratégia para voltar isso? Montar um owner em alguma base de teste ou na sua própria máquina e realizar um IMPORT do owner da aplicação sem registros e posteriormente pegar o DDL da procedure? Pegar os DDL do desenvolvimento ou homologação? Ou mandar o desenvolvedor se virar? Quais as alternativas!
Para resolver esse simples probleminha, basta começar a realizar um backup lógico dos objetos do banco de dados, pode usar as próprias views do dicionário de dados do Oracle, como dba_source, dba_triggers, dba_views, dba_mviews e etc, usar o pacote DBMS_METADATA, gerar um DDL script com o Export ou até mesmo para os adeptos de programas gráficos como PL/SQL Developer, SQL Developer e TOAD gerar um "scriptão" a partir deles!
Nessa simples solução, que pode economizar tempo, menos estresse e agilizar o objeto correto ao banco de dados, vai gastar apenas tempo para preparar os scripts e, posteriormente, realizar os agendamentos necessários e mandar para FITA, eles podem gerados em arquivos com os nomes e tipos dos objetos, um script completo do owner da aplicação com a data do backup e etc. Fica a gosto do cliente!
Percebeu que existem diversos tipos, formas, tamanhos, técnicas, soluções e práticas de backup, uma boa estratégia de backup varia muito conforme o ambiente e os recursos que a empresa oferece, e também as estratégias que o DBA irá implementar na empresa. O banco de dados Oracle oferece para você um leque de opções, basta saber aplicar essas opções. É igual ao antigo slogan do um ótimo produto da NESTLE.
Existem 1001 maneiras de preparar sua Estratégia de backup, invente a sua!
Extractos do texto retirados do site imaster
Nenhum comentário:
Postar um comentário