Clique aqui para ler esse editorial em PDF
Oracle
Oracle 11g New Features – Parte 3
Novidades na ferramenta Recovery Manager - RMAN
O Recovery Manager (RMAN) é a ferramenta da Oracle para gerenciamento e execução de todo o processo de backup e recovery. Esta ferramenta já esta disponível juntamente com a aquisição do próprio banco de dados, ou seja, sua empresa não precisará pagar nada a mais para utilizar a ferramenta.
Até a versão 9i, o RMAN possuía uma série de limitações que, em alguns casos, tornava o processo de backup um tanto quanto inviável, principalmente no tocante a gerenciamento de espaço ocupado pelo backup.
Mas isso já é passado. A partir da versão 10g, o RMAN ficou realmente muito poderoso e definitivamente uma opção bastante viável para diferentes situações encontradas nas empresas. Podemos citar como exemplo uma das empresas que prestamos serviço em que existe uma recomendação para que, qualquer banco de dados que já esteja na versão 10g deva ser utilizado o RMAN como ferramenta de backup e já os bancos de dados nas versões anteriores com tamanho acima de 1T (TeraByte) a recomendação ou melhor, definição, é que seja utilizada uma certa ferramenta de backup proprietária (e paga).
E se na versão 10g a ferramenta já se tornou muito confiável, imagine agora, com novas funcionalidades na versão 11g.
Novas funcionalidades de Backup e Recovery.
Nesta seção descreveremos algumas das novidades presentes na nova versão do RMAN:
Conselheiro de Recuperação de Dados (Data Recovery Advisor)
O Data Recovery Advisor é uma ferramenta para diagnosticar automaticamente falhas nos dados e recomendar os reparos. As falhas poderão ser reparadas manualmente, com base nas recomendações, ou você poderá pedir para que sejam reparadas automaticamente. O Data Recovery Advisor suporta os comandos LIST FAILURE para listar as falhas, CHANGE FAILURE para alterar a prioridade ou abrir/fechar uma falha, ADVISE FAILURE para recomendar a reparação das falhas e REPAIR FAILURE para efetivamente reparar as falhas. Este conselheiro é baseado no Health Check Monitor (visto na Parte 2 deste artigo).
Backup de tablespaces “transportáveis” somente-leitura (read-only transportable tablespaces)
Nas versões anteriores, o RMAN não era capaz de fazer o backup de transportable tablespaces até que elas fossem convertidas para leitura/escrita (read/write) no banco de dados de destino. Agora, na versão 11g, o RMAN já pode fazer o backup de transportable tablespaces mesmo em estado read-only e restaurar normalmente estes backups.
Melhorias de backup e recovery no Oracle Enterprise Manager
Agora, na versão 11g, o Oracle Enterprise Manager possui uma interface gráfica para o Data Recovery Advisor.
Backups em multi-seções
O RMAN pode agora efetuar o backup de um único arquivo do banco de dados (por exemplo) em paralelo, dividindo a tarefa em múltiplos canais. Cada canal fará o backup de uma seção (ou parte) do arquivo. Você poderá criar um backup multi-seção especificando a opção SECTION SIZE no comando de backup. Para restaurar um backup multi-seção não é necessário adicionar nenhuma opção ao comando, o processo é automático.
Pode-se ainda paralelizar a validação do arquivo através da opção VALIDATE ... SECTION SIZE.
Otimização de Undo
O comando BACKUP não efetua mais o backup de informações de Undo que não sejam mais necessárias para a recuperação deste backup. Uma informação de Undo não é mais necessária caso ela tenha sido gerada por uma transação que já foi efetivada (commit) e este tipo de informação representa a maior parte de informações de Undo de todo o banco de dados. É bom lembra que este tipo de comportamento passou a ser o comportamento padrão do RMAN na versão 11g do Oracle e não há como desabilitar.
Melhoria no desempenho de recuperação de blocos
Ao executar uma recuperação de bloco (Block Media Recovery), o RMAN automaticamente procura por flashback logs (Nota DevMan 1), caso estejam disponíveis, para o bloco em questão a ser recuperado antes de procurar pelo bloco no backup. Ao utilizar os blocos encontrados no flashback log, a recuperação terá o seu desempenho sensivelmente melhor.
Nota DevMan 1: Flashback log
O Oracle gera arquivos de log usados para executar operações de flashback no banco de dados. O banco de dados pode criar os flashback logs apenas em uma área chamada flash recovery area. Os flashback logs são escritos seqüencialmente e não são arquivados e também não podem ser copiados (backup) para disco.
Melhoria na detecção de corrupção de blocos
Vários componentes e utilitários de banco de dados, incluindo o RMAN, agora podem detectar uma corrupção de bloco e armazenar estas informações na view V$DATABASE_BLOCK_CORRUPTION.
Quando a recuperação da instância (instance recovery) detecta um bloco corrompido, automaticamente a informação é armazenada na view. O Oracle automaticamente atualiza esta view quando uma corrupção de bloco é detectada ou reparada. Finalmente, o comando VALIDATE foi melhorado com algumas novas opções como VALIDATE ... BLOCK e VALIDATE DATABASE.
Compressão de backup mais rápida
Além do algoritmo BZIP2 para compressão binária de backups, o RMAN agora suporta também o algoritmo ZLIB. Este algoritmo é executado mais rapidamente que o BZIP2, porém produz arquivos maiores. Você poderá utilizar o comando CONFIGURE COMPRESSION ALGORITHM para escolher entre o BZIP2 (padrão) e o ZLIB para os backups do RMAN. Perceba que a escolha será entre uma compressão maior porém mais lenta e uma compressão menor porém mais rápida.
Melhoria nos scripts do RMAN através da utilização de variáveis de substituição
Podemos agora criar arquivos de comandos do RMAN e armazená-los em scripts que aceitam entradas do usuário no momento da execução, por exemplo. Desta forma, scripts de backup do RMAN podem utilizar variáveis de substituição para tags, nomes de arquivos, nomes para pontos de restauração (restore point) e tudo o mais.
Backup failover para archived redo logs na flash recovery area
Ao executar o backup de archived redo log files (Nota DevMan 2) localizados na flash recovery area (Nota DevMan 3), o RMAN pode efetuar um failover (Nota DevMan 4) para armazenar os archived redo log files em um local fora da flash recovery area. O RMAN tem a capacidade de usar uma cópia que esteja perfeita de um archived redo log em um local alternativo para continuar “escrevendo” o backup caso o log esteja faltando ou corrompido na flash recovery area.
Nota DevMan 2: Archived redo log files
Um archived redo log file é uma cópia de um membro de um group de online redo log quando o banco de dados opera em modo ARCHIVELOG. Após o processo de segundo plano LGWR preencher cada online redo log com informações de redo, o processo de arquivamento cria uma cópia deste online redo log para um ou mais destinos em disco. Note que o RMAN não faz distinção entre o arquivo original ou uma imagem do archived redo log; para ele, todos são considerados imagens.
Nota DevMan 3: Flashback recovery area
A flash recovery area é um local opcional em disco que poderá ser usado para armazenar arquivos relacionados à recuperação do banco de dados como o arquivo de controle (control file), as cópias dos online redo logs, archived redo log files, flashback logs e backups do RMAN. O banco de dados Oracle e o RMAN gerenciam os arquivos armazenados na flashback recovery area automaticamente. É possível ainda especificar a cota em disco, que é o tamanho máximo da flashback recovery area.
Nota DevMan 4: Failover
Failover é a capacidade de alterar automaticamente o sistema, banco de dados ou rede de dados do servidor ativo para um servidor redundante ou standby em caso de falha. O failover ocorre sem a intervenção humana e, geralmente, sem alarmes.
Este tipo de infra-estrutura é normalmente utilizado em bancos de dados que necessitam de alta disponibilidade.
Melhoria na política de exclusão de Archived redo log
Quando você configura a política de exclusão de archived redo log, a configuração é aplicada a todos os destinos de armazenamento, inclusive a flashback recovery area. Ambos os comandos BACKUP ... DELETE INPUT e DELETE ... ARCHIVELOG obedecem esta configuração da mesma forma que a flashback recovery area" [...] continue lendo...
