Pedro F. Carvalho Analista de Sistemas AULA 16 RECOVERY

Transcrição

1 AULA 16 RECOVERY 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 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 é

2 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. A versão 11g do Oracle trouxe várias melhorias ao RMAN, e embora não possamos explicar todas detalhadamente neste espaço, listamos todas a seguir, com uma pequena explicação: RMAN 11gR1: Archive Log Management Improvements: garante que ARCHIVED REDO LOGs só são removidos quando não são mais necessários (por exemplo, para Data Guard Nota DevMan 1 -, Streams, ou Flashback);

3 Nota DevMan 1. Data Guard Oracle Data Guard garante alta disponibilidade, proteção dos dados e recuperação de dados em caso de desastre. Data Guard fornece um conjunto abrangente de serviços para criar, manter, gerenciar e monitorar um ou mais bancos de dados em standby para permitir que bancos de dados de produção sobrevivam a desastres e corrupção de dados. Data Guard mantém esses bancos de dados standby como cópias do banco de dados de produção. Com isso, se os dados de produção ficarem indisponíveis por uma parada planejada ou não planejada, o Data Guard pode mudar qualquer banco em standby para o papel de produção, minimizando o tempo de inatividade associado a interrupção. Fast Incremental Backups on Physical Standby Database: Faz com que Backups que utilizam Block Change Tracking (Nota DevMan 2) possam ser feitos no Data Guard; Nota DevMan 2. Block Change Tracking Uma opção do banco de dados que faz com que o Oracle rastreie os blocos afetados por cada atualização de banco de dados. As informações de rastreamento são armazenadas em um arquivo de rastreamento chamado Change Tracking File. Quando o Block Change Tracking está habilitado, o RMAN usa o registro de blocos alterados a partir do Change Tracking File para melhorar o desempenho de backups incrementais somente lendo as informações dos blocos que foram alterados, ao invés de ler todo o datafile. Improved Backup Compression Performance: permite a utilização do algoritmo de compressão BZIP2, como demonstraremos neste artigo; Improved Integration with Data Guard: traz várias melhorias, como poder manter um backup só para o ambiente de produção e para o Data Guard; Network-Aware DUPLICATE Command: não é mais necessário ter um backup pronto para criar-se um clone de um banco de dados; Optimized Undo Backup: só é feito Backup do que é necessário de uma tablespace de UNDO, diminuindo seu tamanho total e tempo de execução; Read-Only Transported Tablespaces Backup: torna possível o Backup de tablespaces apenas de leitura; Virtual Private Catalog: permite limitar a visualização do Catalog por usuário; Data Recovery Advisor: é uma ferramenta que diagnostica falhas e já reporta as opções de recuperação, podendo executá-las automaticamente. Demonstraremos seu uso logo mais; Enhance LogMiner to Support Automatic Data Repair: permite utilizar o Log Miner mesmo quando o banco de dados não está disponível; Integrated Protection From Various Data Corruptions: várias proteções extras contra corrupção de dados; Lost-Write Detection Using a Physical Standby Database: proteção contra escritas que não acontecem realmente no Storage. RMAN 11gR2: Automatic Block Repair: faz com que um bloco corrompido seja automaticamente reparado, buscando-se do ambiente Data Guard; Backup to Amazon Simple Storage Service (S3) Using OSB Cloud Computing: permite a execução de Backups direcionados para o serviço de Cloud Computing da Amazon (Nota DevMan 3);

4 Nota DevMan 3. Cloud Computing A nuvem computacional ou cloud computing consiste em compartilhar ferramentas computacionais pela interligação dos sistemas, ao invés de ter essas ferramentas localmente (mesmo nos servidores internos). O uso desse modelo (ambiente) é mais viável do que o uso de unidades físicas. Um problema originado dentro das corporações é o alto custo com Tecnologia da Informação (TI). As organizações de TI gastam hoje 80% de seu tempo com a manutenção de sistemas e não é seu objetivo de negócio manter dados e aplicativos em operação. É dinheiro jogado fora, o que é inaceitável nos dias de hoje, defende Clifton Ashley, diretor do Google para a América Latina. Dentro desse contexto, o PC será apenas um chip ligado à internet, a "grande nuvem" de computadores. Não há necessidade de instalação de programas, serviços e armazenamento de dados, mas apenas os dispositivos de entrada (teclado, mouse) e saída (monitor) para os usuários. Uma arquitetura em nuvem é muito mais que apenas um conjunto (embora massivo) de computadores. Ela deve dispor de uma infra-estrutura para gerenciamento, que inclua funções como provisionamento de recursos computacionais, equilíbrio dinâmico do workload e monitoração do desempenho. DUPLICATE Without Connection to Target Database: permite que um clone seja feito, mesmo que o banco primário esteja indisponível; Enhanced Tablespace Point-In-Time Recovery (TSPITR): traz várias melhorias de recuperação apenas de uma tablespace, como poder recuperar tablespaces que foram removidas; New DUPLICATE Options: várias opções que facilitam a clonagem de bancos de dados, como o NOREDO, que torna desnecessário duplicar os REDO LOGs; New SET NEWNAME Clauses and Format Options: permite mudança de nomes de tablespaces e até do banco de dados durante uma clonagem; Tablespace Checks in DUPLICATE: antes de excluir uma tablespace de uma operação de clonagem, algumas verificações são feitas, como por exemplo, a existência de objetos do usuário SYS residentes nesta tablespace. Mão na Massa A seguir, iremos demonstrar como utilizar o RMAN do 11g para executar seus Backups, e inclusive demonstrar o uso de algumas de suas novas funcionalidades. Para executar os procedimentos descritos neste artigo, você precisará de um banco de dados 11g (versões R1 ou R2) como ambiente de testes. Primeiramente, temos que ter certeza que o banco está configurado para utilizar o modo ARCHIVELOG. Um banco de dados Oracle de produção deve estar em modo ARCHIVELOG para ter sua recuperabilidade garantida. Veja na Listagem 1 como alterar o banco de dados para o modo ARCHIVELOG. Listagem 1. Comandos para colocar o banco de dados em modo ARCHIVELOG. 1. [oracle@labdb ~]$ sqlplus / AS SYSDBA 2. SQL*Plus: Release Production on Thu Jul 23 11:41: Copyright (c) 1982, 2008, Oracle. All rights reserved. 4. Connected to: 5. Oracle Database 11g Enterprise Edition Release Production 6. With the Partitioning, OLAP, Data Mining and Real Application Testing options

5 7. SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u01/archives' SCOPE=SPFILE; 8. System altered. 9. SQL> SHUTDOWN IMMEDIATE; 10. Database closed. 11. Database dismounted. 12. ORACLE instance shut down. 13. SQL> STARTUP MOUNT; 14. ORACLE instance started. 15. Total System Global Area bytes 16. Fixed Size bytes 17. Variable Size bytes 18. Database Buffers bytes 19. Redo Buffers bytes 20. Database mounted. 21. SQL> ALTER DATABASE ARCHIVELOG; 22. Database altered. 23. SQL> ALTER DATABASE OPEN; 24. Database altered. 25. SQL> EXIT; 26. Disconnected from Oracle Database 11g Enterprise Edition Release Production 27. With the Partitioning, OLAP, Data Mining and Real Application Testing options 28. [oracle@labdb ~]$ Vejamos o que acontece na Listagem 1. Na linha 1, conectei ao banco de dados como SYSDBA. Na linha 7, alterei o parâmetro LOG_ARCHIVE_DEST_1 para indicar a localização em que os archived redo log files serão armazenados, alterando o parâmetro apenas no SPFILE. Na linha 9, fechei o banco de dados. Na linha 13, iniciei o banco de dados em modo mount para informar ao banco de dados que ele deve começar a operar em modo archivelog (linha 21) e finalmente abri o banco de dados (linha 23). Na Listagem 2, demonstramos como criar o Catalog do RMAN. Neste exemplo, por ser apenas um teste, criamos o Catalog no mesmo banco de dados, mas obviamente isto não é o ideal - se o banco estiver indisponível, o Catalog também estará. Então, em um ambiente de produção, o Catalog deve estar em outro servidor.