BLOG RODRIGO ALMEIDA

Olá,

Vou mostrar uma tática bem legal de diminuir um banco de dados Oracle físicamente, sem mexer em extents (por shrink table), rebuild de índices ou realizar desfragmentação de segmentos (por Export\Import Utility) no banco de dados.

O principal ponto que iremos atacar será os espaços livres desnecessários alocados na tablespace, que consomem espaços em disco preciosos no sistema operacional, toda essa tarefa será guiada atráves da marca d’água (HWM – High Water Mark) dos datafiles onde podemos realizar um RESIZE no datafile para um valor menor sem a perda de dados.

Lembrete

Essa tarefa envolve alguns conceitos de Oracle, como os de Marca D’água, ou HWM – High Water Mark, esse tema eu vou abordar em outro post para melhor entendimento. OK!

Para iniciarmos os trabalhos, vamos analisar o tamanho do nosso banco de dados e quanto ele está ocupando em disco, abaixo, vou fazer dois SELECTS que passa essas informações para nós e depois um print da quantidade em disco utilizado e livre no sistema operacional.

select sum(bytes)/1024/1024 as "TamanhoFisico(MB)" from dba_data_files;

TamanhoFisico(MB)
—————–
76000

col "FileSystem" format a12

select substr(file_name,1,4) as "FileSystem", sum(bytes)/1024/1024 as "Tamanho(MB)"
from dba_data_files
group by rollup(substr(file_name,1,4))
order by substr(file_name,1,4);

FileSystem Tamanho(MB)
———— ———–
/u01 25800
/u02 50200
76000

Percebemos, que no meu banco de dados, tenho quase 26GB de datafiles no FileSystem /u01 e mais 50GB no FileSystem /u02, totalizando os 76GB que é o tamanho total do meu banco de dados. O importante é saber o que esse valor representa na minha máquina, em questão de consumo e escabilidade, veja o que a máquina ainda pode oferecer.

[oracle@pelspos18 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 9.9G 3.2G 6.3G 34% /
/dev/sda1 190M 13M 168M 8% /boot
none 2.0G 0 2.0G 0% /dev/shm
/dev/sda5 2.0G 36M 1.9G 2% /tmp
/dev/sda6 114G 51G 58G 48% /u01
/dev/sdb1 134G 50G 78G 40% /u02

Para o FileSystem /u01, representa 48% de utilização, já para o FileSystem /u02, representa 40% de utilização. Claro, que tudo isso, irá depender de como o aplicativo e banco de dados se comporta, se é um banco de dados com crescimento acentuado diário, mensal ou semestral, tudo isso influência. Mas, no exemplo que estou utilizando, o banco de dados tem um crescimento em média de 3GB por mês, então, está adequado.

Mas, eu preciso liberar mais espaço em disco para fazer alguns backups em disco, exports e etc. Então, vou diminuir meu banco de dados físicamente de forma segura, como eu disse no início do post.

Para fazer isso, preciso da mais algumas informações como, Tamanho Físico e Livre das tablespace, que pode ser pego facilmente pelos SELECTS abaixo.

select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)"
from dba_data_files
group by tablespace_name
order by sum(bytes);

TABLESPACE_NAME TAMANHO(MB)
——————– ———–
FIN_CPAG 400
FIN_CEXT_IDX 800
USERS 800
TOOLS 1500
SYSAUX 2000
SYSTEM 2000
FIN_CORP 3500
FIN_CORP_IDX 5000
FIN_CPAG_IDX 8000
UNDOTBS 10000
FIN_CREC_IDX 12000
FIN_CREC 30000

12 linhas selecionadas.

Bom, as tablespaces SYSTEM e SYSAUX não é novidade para ninguem, então, elas vou deixar-las de fora da atividade, para não ocorrer nenhum tipo de problema. Vou apenas pensar nas demais, inclusive na de UNDO. Perceba que esse é apenas um SELECT para ver o tamanho total das tablespaces, agora, quero saber quanto cada uma tem livre, para poder direcionar os RESIZES. Abaixo segue o tamanho livre por tablespace.

select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)"
from dba_free_space
group by tablespace_name
order by sum(bytes);

TABLESPACE_NAME TAMANHO(MB)
——————– ———–
FIN_CREC_IDX 2,1875
FIN_CPAG 398,5625
USERS 642,5625
FIN_CEXT_IDX 799,5625
TOOLS 1495,3125
SYSTEM 1738,8125
SYSAUX 1869,125
FIN_CORP_IDX 2456,4375
FIN_CORP 3259,6875
FIN_CPAG_IDX 5289,375
FIN_CREC 8625,125
UNDOTBS 9865,375
12 linhas selecionadas.

Apenas mudei a view do primeiro SELECT, de dba_data_files para dba_free_space. Com isso, podemos ver quem tem mais espaço livre e saber quem precisa, existe tablespace com 8GB livres, e outros com 2,3 e 5G livres, só nisso, deixando apenas 10% livre, podemos economizar 12GB em disco. E ainda sem pensar no UNDO.

Agora, vamos executar um SELECT que irá analisar a marca d’água dos datafiles e verificar se existe a possibilidade de realizar um RESIZE para um valor menor, com isso, liberar espaço em disco no sistema operacional. Esse SELECT precisa de uma atenção especial, pois, é necessário informar o tamanho do db_block_size do seu banco de dados para efetuar corretamente os cálculos.

Para saber o tamanho do seu db_block_size, basta fazer o seguinte procedimento.

NO SQLPLUS, faça:

show parameters db_block_size

NAME TYPE VALUE
———————————— ———– ——————————
db_block_size integer 8192

Se preferir, poderá ver na v$parameter, como no exemplo.

col name format a15

col value format a15

select name, value from v$parameter where name = 'db_block_size';

NAME VALUE
————— —————
db_block_size 8192

Agora, o momento esperado, o SELECT para realizar a operação de resize, veja.

select 'alter database datafile ''' || file_name || ''' resize ' ||
ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 )  || 'm;' cmd
from dba_data_files a,
( select file_id, max(block_id+blocks-1) hwm
  from dba_extents
  group by file_id ) b
where a.file_id = b.file_id(+)
and ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) < ceil( blocks*8192/1024/1024)
and ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) > 100

Lembrete
Veja que onde está 8192 no script acima, é referente ao tamanho do db_block_size do seu banco de dados, esse valor então poder ser 2048, 4096, 8192, 16384 e 32768.

O script acima irá gerar um resultado sobre espaço livre, tamanho atual, espaço que pode ser salvo, total de espaço que pode ser liberado por datafile do seu banco de dados, tudo isso gerado pelos cálculos sobre a marca d’água de cada datafile. Se atentem pois ele está pegando todas as tablespaces do banco de dados e isso para nós não é necessário, podemos excluir a tablespace SYSTEM e SYSAUX.

FILE_NAME SMALLEST CURRSIZE SAVINGS SMALLEST_SAFE SAVINGS_SAFE
———————————————————— ———- ———- ———- ————- ————
/u02/app/oracle/oradata/finp/fin_corp01.dbf 125 2000 1875 149 1851
/u02/app/oracle/oradata/finp/sysaux01.dbf 191 2000 1809 229 1771
/u02/app/oracle/oradata/finp/system01.dbf 264 2000 1736 316 1684
/u02/app/oracle/oradata/finp/fin_corp02.dbf 117 1500 1383 140 1360
/u01/app/oracle/oradata/finp/fin_cpag_idx04.DBF 643 2000 1357 771 1229
/u01/app/oracle/oradata/finp/fin_cpag_idx03.dbf 651 2000 1349 781 1219
/u01/app/oracle/oradata/finp/fin_cpag_idx02.dbf 692 2000 1308 830 1170
/u01/app/oracle/oradata/finp/fin_cpag_idx01.dbf 728 2000 1272 873 1127
/u01/app/oracle/oradata/finp/fin_corp_idx02.dbf 847 2000 1153 1016 984
/u01/app/oracle/oradata/finp/fin_corp_idx01.dbf 897 2000 1103 1076 924
/u02/app/oracle/oradata/finp/fin_crec09.dbf 1284 2000 716 1540 460
/u02/app/oracle/oradata/finp/fin_crec08.dbf 1288 2000 712 1545 455
/u02/app/oracle/oradata/finp/fin_crec07.dbf 1304 2000 696 1564 436
/u02/app/oracle/oradata/finp/fin_crec06.dbf 1314 2000 686 1576 424
/u02/app/oracle/oradata/finp/fin_crec05.dbf 1331 2000 669 1597 403
/u02/app/oracle/oradata/finp/fin_crec04.dbf 1334 2000 666 1600 400
/u02/app/oracle/oradata/finp/fin_crec01.dbf 1351 2000 649 1622 378
/u02/app/oracle/oradata/finp/fin_crec02.dbf 1351 2000 649 1621 379
/u02/app/oracle/oradata/finp/fin_crec03.dbf 1351 2000 649 1621 379
/u02/app/oracle/oradata/finp/users01.dbf 158 800 642 189 611
/u02/app/oracle/oradata/finp/fin_crec15.dbf 1427 2000 573 1712 288
/u02/app/oracle/oradata/finp/fin_crec14.dbf 1547 2000 453 1856 144
/u02/app/oracle/oradata/finp/fin_crec13.dbf 1549 2000 451 1858 142
/u02/app/oracle/oradata/finp/fin_crec12.dbf 1551 2000 449 1861 139
/u02/app/oracle/oradata/finp/fin_crec11.dbf 1603 2000 397 1923 77
/u01/app/oracle/oradata/finp/fin_corp_idx03.dbf 802 1000 198 962 38

26 linhas selecionadas.

CMD
——————————————————————————
alter database datafile ‘/u02/app/oracle/oradata/finp/system01.dbf’ resize 316m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec11.dbf’ resize 1923m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec02.dbf’ resize 1621m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec07.dbf’ resize 1564m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_corp02.dbf’ resize 140m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec05.dbf’ resize 1597m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec06.dbf’ resize 1576m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec03.dbf’ resize 1621m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec08.dbf’ resize 1545m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_corp_idx01.dbf’ resize 1076m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec01.dbf’ resize 1622m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec09.dbf’ resize 1540m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec12.dbf’ resize 1861m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec14.dbf’ resize 1856m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec15.dbf’ resize 1712m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_cpag_idx01.dbf’ resize 873m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_cpag_idx04.DBF’ resize 771m;
alter database datafile ‘/u02/app/oracle/oradata/finp/sysaux01.dbf’ resize 229m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec13.dbf’ resize 1858m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec04.dbf’ resize 1600m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_cpag_idx02.dbf’ resize 830m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_corp01.dbf’ resize 149m;
alter database datafile ‘/u02/app/oracle/oradata/finp/users01.dbf’ resize 189m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_corp_idx02.dbf’ resize 1016m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_corp_idx03.dbf’ resize 962m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_cpag_idx03.dbf’ resize 781m;

26 linhas selecionadas.

Uma coisa boa que essse script já fornece o comando de DDL para redimensionar o datafile da tablespace sem a perda de dados. Basta executar.

Após a execução dos scripts, vamos analisar os resultados gerados. Primeiramente, vamos ver agora o tamanho total e o espaço livre das tablespaces, depois verificar como ficou o espaço em disco no sistema operacional e saber o quanto ganhamos com isso.

Espaço total das tablespace

select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)"
from dba_data_files
group by tablespace_name
order by sum(bytes);

TABLESPACE_NAME TAMANHO(MB)
——————– ———–
USERS 189
FIN_CORP 289
FIN_CPAG 400
FIN_CEXT_IDX 800
TOOLS 1500
SYSAUX 2000
SYSTEM 2000
FIN_CORP_IDX 3054
FIN_CPAG_IDX 3255
UNDOTBS 10000
FIN_CREC_IDX 12000
FIN_CREC 25496

12 linhas selecionadas.

Espaço livre nas tablespace

select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)"
from dba_free_space
group by tablespace_name
order by sum(bytes);

TABLESPACE_NAME TAMANHO(MB)
———————– ———–
FIN_CREC_IDX 2,1875
USERS 31,5625
FIN_CORP 48,6875
FIN_CPAG 398,5625
FIN_CORP_IDX 510,4375
FIN_CPAG_IDX 544,375
FIN_CEXT_IDX 799,5625
TOOLS 1495,3125
SYSTEM 1737,3125
SYSAUX 1811,5
FIN_CREC 4121,125
UNDOTBS 9797,4375

12 linhas selecionadas.

Espaço no sistema operacional

[oracle@pelspos18 u01]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 9.9G 3.2G 6.3G 34% /
/dev/sda1 190M 13M 168M 8% /boot
none 2.0G 0 2.0G 0% /dev/shm
/dev/sda5 2.0G 36M 1.9G 2% /tmp
/dev/sda6 114G 45G 64G 42% /u01
/dev/sdb1 134G 42G 86G 33% /u02

Conclusões

Perceba que algumas tablespace permaneceram do mesmo tamanho e algumas tiveram mais que 10% do seu tamanho reduzido, o melhor que podemos notar no sistema operacional que o FileSystem /u02 que antes tinha 78GB disponível, agora tem 86GB, uma diferença de 8GB, para o FileSystem /u01 que atens tinha 58GB disponível, agora tem 64GB, uma diferença de 6GB, que somando com o valor anterior, podemos reutilizar 14GB de espaço no sistema operacional.

O tamanho do nosso banco de dados fisicamente, também diminuiu, foi para 62GB. Antes era de 76GB, 14GB a menos, justamente o que nós não utilizamos mais.

O que pode nos ajudar a redução física do banco de dados?

Pode nos ajudar em N tarefas, como:

• Não deixar o banco de dados travar por problemas de ARCHIVE ERROR;
• Reaproveitamente de espaço em disco;
• Diminuição de arquivos de backup gerados pelo RMAN em nível 0;
• Ajuda na escabilidade do servidor;

Acho que isso já são boas razões para se pensar em fazer uma diminuição física do seu banco de dados.

Abraços,

Olá,

Um assunto muito pouco abordado entre os profissionais Oracle e que sempre causa estresse e problemas quando necessário, e a eficiência da estratégia de backup & recover de um determinado banco de dados da empresa, pois todos só prestam atenção nesse assunto quanto é necessário e já está com a corda no pescoço.

Para ter uma eficiente estratégia de backup & recover, primeiramente deve-se conhecer a infra-estrutura que a empresa oferece para adequar as soluções de backup e planejar quais estratégias e técnicas que serão aplicadas. E quando estamos falando de infra-estrutura, diversos pontos devem ser destacados, como:

• Rede LAN dedicada para backup & recover;
• Dispositivos de Fita (DLT, LTO e DDS) disponíveis para armazenamento;
• Se existe uma necessidade de storage para backup em disco, é viável uma aquisição?;
• Se existe servidores dedicados para testes e validação de restore e recover;
• A empresa possui outro site para planejar estratégias de backup;
• Se a empresa centraliza backups de outras unidades, qual o tamanho da banda de rede.

O segundo ponto que deve ser analisado é a politíca de backup de cada banco de dados, tratado de forma única, pois em banco de dados, pelo mais que seja padronizado as instalações, arquitetura e funcionalidades de cada base, necessita de políticas de backup customizadas, onde a aplicação da empresa que irá ditar as principais regras, e existem pontos que merecem atenção, como:

• Tempo para janela de recuperação;
• Tempo de retenção dos dados;
• Agendamento das rotinas de backup, exemplo: diáriamente, semanalmente, mensalmente ou anual;
• Volumetria que será armazenada;
• Nível de proteção dos dados;
• Tipos de backups que serão executados;
• Definicação dos procedimentos de backup, restore e recover.

Os dois pontos citados, é o início para enxergar as deficiências da empresa ao elaborar as estratégias de backup, são os principais pontos que devem ser levantados para posteriormente planejar as melhores técnicas e politícas adequadas para as bases.

Não adianta o DBA ter diversas ideias e soluções de armazenamento e recuperações ótimas se a empresa não permite ou não suporta tais tarefas. Seria uma frustação ao profissional tentar implementar uma solução sem sucesso ou com diversos problemas e que não consegue atingir o principal objetivo que é a segurança dos dados e disponibilidade do banco de dados.

Em relação ao assunto, soluções de backup,  existem diversas no mercado, a própria Oracle oferece diversas soluções de backup interessantes, como Oracle Secure Backup, Data Guard, Stand-by Database, Recovery Manager (RMAN) e Legato Single Server. Outros produtos de terceiros podem oferecer soluções adequadas a sua empresa, como: CA BrightStor ArcServer e Backup Exec, Symantec NetBackup, IBM Tivoli ou EMC NetWorker. Tudo é uma questão de analise, planejamento e execução na implantação da solução, e é claro, verificar se o valor da solução está dentro do orçamento do departamento de TI.

Agora, aos DBAs, existem técnicas e práticas que podemos aplicar, para complementar as estratégias de backup existentes e outras práticas que devem possuir requisitos citados no início, principalmente na parte de infra-estrutura. Quando vamos pensar em backup & recover, O que lhe vem na cabeça? Vamos montar uma lista com as opções:

1. Backup cold;
2. Backup hot;
3. Backup por tablespace;
4. Backup do control file;
5. Export do banco de dados;
6. Arquivos de carga (originadas do ETL ou de algum outro processo);
7. Cópia fria de um servidor para o outro;
8. Cópia dos objetos de banco;
9. E no pior das hípoteses, garantia de alguma coisa no ambiente de desenvolvimento e homologação.

OK! Percebeu que estamos falando de um assunto delicado e de forma abrangente, sem determinar o que será feito, se existe procedimento para tal, quais as garantias que vou ter e sempre pensando naquela frase linda e determinante:

“Backup bom é aquele que volta”

Agora, vamos discutir um pouco sobre os tipos de backups citados acima.

Backup Frio (Cold Backup), backup realizado com o banco de dados offline, ou seja consistente.

O backup cold pode ser feito de modo automatizado atráves do RMAN (Recovery Manager) ou atráves 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 dado 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, e geralmente para uma empresa isso 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 foi apagado 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, porquê 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 aberto 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 porquê 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 scripts 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.

“Existe 1001 maneiras de preparar sua Estratégia de backup, invente a sua!”

E Ficamos por aqui, dúvidas, críticas e sugestões, só entrar em contato.

Abraços,