2/25/2013

OCP 11g – Arquitetura do Banco de Dados.

Estruturas lógicas de armazenamento

Os datafiles do Oracle são agrupados em um ou mais tablespaces;
Datafiles são estruturas físicas subdivididas em extents e blocks;
Um tablespace pode ser visto como um grupo lógico de datafiles;
Em cada tablespace existem estruturas lógicas do banco de dados, como tabelas e índices;
O termo “segmento” é utilizado para descrever o espaço físico ocupado por uma tabela (ou outros objetos);
O Oracle é dividido em compartimentos para propiciar um controle mais eficiente do uso do espaço em disco.

Tablespaces

Um tablespace do Oracle é um agrupamento lógico de um ou mais datafiles. Um datafile faz parte de um (e somente um) tablespace. A instalação padrão do Oracle 11g cria seis tablespaces, mas o mínimo são apenas dois: SYSTEM e SYSAUX. Estes dois tablespaces são indispensáveis.

O Oracle 11g permite a criação de tablespaces de um tipo especial, chamado tablespace bigfile, que pode ter até 128TB de tamanho.

Se um tablespace for temporário, somente os segmentos gravados no tablespace serão temporários. O tablespace e si é permanente. Tablespaces temporárias são utilizadas para operações de classificação (order by) e para tabelas temporárias, ou seja, que existem apenas durante a sessão do usuário.

Os tablespaces podem ser gerenciados localmente ou gerenciados pelo dicionário. A diferença está no gerenciamento de extents: enquanto um tablespace gerenciado pelo dicionário registra o gerenciamento de extents no dicionário de dados, o tablespace gerenciado localmente armazena um bitmap no cabeçalho de cada datafile pertencente ao tablespace para rastrear a disponibilidade de espaço. O gerenciamento local oferece a grande vantagem de evitar alta concorrência sobre as tabelas do dicionário de dados.

Blocks

Um block (bloco) do banco de dados é a menor unidade de armazenamento no Oracle. O tamanho de um bloco é um número específico de bytes de armazenamento em um determinado tablespace dentro do banco de dados.

O tamanho de bloco é especificado no parâmetro DB_BLOCK_SIZE. Este tamanho geralmente é um número múltiplo do tamanho de bloco do sistema operacional, para um melhor desempenho de I/O.

Extents

Extent (extensão) é o nível seguinte do agrupamento lógico no banco de dados, ou seja, ele consiste em um ou mais blocos do banco de dados. Quando um objeto do banco de dados solicita mais espaço (uma tabela sofrendo um INSERT, por exemplo), o espaço adicionado ao objeto é alocado como um extent.

Segments

Segment (segmento) é um grupo de extensões que forma um objeto do banco de dados. Portanto, um objeto qualquer do banco de dados (uma tabela, ou um índice, por exemplo) tem seus dados armazenados em um segment. Um objeto tem apenas um segmento (que pode crescer de tamanho alocando mais extents), com exceção de objetos particionados ou clusterizados. Uma tabela particionada ou um índice particionado, por exemplo, tem um segmento para cada partição.

Estruturas físicas de armazenamento


Veremos abaixo um pouquinho sobre cada uma das estruturas físicas de armazenamento do Oracle Database.

Datafiles

Um datafile corresponde a um único arquivo de sistema operacional no disco;

Cada datafile é membro de um tablespace, porém cada tablespace pode ter vários datafiles;

Um datafile pode expandir automaticamente quando atingir seu espaço alocado, através do parâmetro AUTOEXTEND;

Esta expansão pode ser limitada pelo parâmetro MAXSIZE;

Independente do caso acima, o tamanho de um datafile é limitado pelo espaço disponível do disco físico no qual ele reside;

O datafile é o local de armazenamento definitivo de todos os dados contidos no banco de dados;

Os blocos mais acessados em um datafile são armazenados em cache na memória (obviamente, somente enquanto a instância está aberta);

A gravação dos blocos alterados no cache da memória são gravados de forma assíncrona nos datafiles, e somente quando o processo database writer estiver ativo.

Redo Log Files

Sempre que forem adicionados, removidos ou alterados dados em uma tabela, índice ou outro objeto do Oracle, uma entrada será gravada no redo log file atual. O Oracle deve possuir pelo menos dois arquivos de redo log, porque ele utiliza de forma circular. Quando um redo log é preenchido até o limite, o próximo arquivo é reutilizado.

Quando ocorre alguma falha (por exemplo, falta de energia no servidor), alguns blocos de dados que foram atualizados no database buffer cache podem não ter sido gravados nos datafiles. Quando a instância for reinicializada, as entradas no redo log serão aplicadas aos datafiles do banco de dados em uma operação de roll-forward para restaurar o estado do banco de dados até o ponto em que a falha ocorreu.

É altamente recomendado que os arquivos de redo log sejam multiplexados, ou seja, tenham uma ou mais cópias ativas para garantir disponibilidade e integridade dos dados. A perda de um redo log que não tenha cópia pode causar perda de dados.

Archive Logs

O Oracle Database pode funcionar de dois modos: ARCHIVELOG ou NOARCHIVELOG.

O modo ARCHIVELOG envia um arquivo de redo log preenchido (após o mesmo sofrer um switch automático, quando o arquivo é totalmente preenchido, ou quando ocorre um switch log de forma manual) para um ou mais destinos especificados e podem ficar disponíveis para recuperação do banco de dados a qualquer momento – caso ocorra uma falha na mídia do banco de dados.

Se uma unidade de disco contendo datafiles falhar, o conteúdo do banco de dados pode ser recuperado até um determinado ponto no tempo antes da falha. Para isto é necessário: um backup recente dos datafiles, os arquivos de redo log e os archive logs gerados a partir do backup.

Em contrapartida, o modo NOARCHIVELOG não garante integridade do banco de dados na ocorrência de uma falha de instância ou de sistema. As trasanções que sofreram commit mas que ainda não foram gravadas nos datafiles estão disponíveis apenas nos arquivos de redo log online. Sendo assim, a recuperação de uma falha estará limitada às entradas existentes atualmente nos redo logs online. Se o último backup foi realizado antes do primeiro arquivo de redo log, então não será possível recuperar o banco de dados – os dados gerados após este backup serão perdidos.

Control Files

O Oracle tem pelo menos um controlfile que mantém os metadados do banco de dados. Metadados são os dados sobre a estrutura física do próprio banco de dados (as definições de tabelas e campos). Entre outros aspectos, o controlfile contém o nome do banco de dados, a data de criação do banco de dados, os nomes e localizações de todos os datafiles e redo log files. O controlfile também preserva informações utilizadas pelo RMAN (Recovery Manager), como configurações persistentes do RMAN e tipos de backups realizados.Sempre que ocorrem alterações na estrutura do banco de dados, as informações sobre essas mudanças serão imediatamente refletidas no controlfile.

O controlfile é um arquivo muito crítico para a operação do banco de dados, e por isso pode (e deve) ser multiplexado e copiado para backup com frequência.

Parameter Files

Os parameter files especificam as localizações dos trace logs, dos archive logs, entre outros arquivos. Também definem os limites para os tamanhos das diversas estruturas de memória existentes na SGA, a quantidade de usuários que podem se conectar simultaneamente ao banco de dados, dentre várias outras configurações.

São dois os tipos de parameter files:

PFILE: arquivo baseado em texto, comumente conhecido como init.ora (por padrão é definido como init.ora);

SPFILE: arquivo binário, por padrão é definido como spfile.ora;

Ao executar um startup, a instância procura primeiro um SPFILE na localização padrão do sistema operacional – $ORACLE_HOME/dbs no Unix ou Linux, por exemplo, como spfile.ora ou spfile.ora. Se nenhum dos dois for encontrado, a instância procura um PFILE chamado init.ora. Como alternativa, o comando STARTUP pode especificar explicitamente um PFILE a ser usado na inicialização do Oracle.

O PFILE, por ser um arquivo texto, pode ser manipulado sem maiores complicações. Pode ser editado manualmente para setar novos parâmetros, ou alterar valores de parâmetros já existentes.

O SPFILE é um arquivo binário, e jamais deve ser alterado manualmente – qualquer alteração irá danificar o arquivo. Apesar disto, o SPFILE é muito vantajoso pois torna mais eficaz o gerenciamento de parâmetros para o DBA. Se um SPFILE estiver sendo usado na instância em execução, qualquer comando ALTER SYSTEM que altere um parâmetro de inicialização poderá mudar automaticamente o parâmetro de inicialização no SPFILE, ou então mudar somente a instância em memória, ou ambos.

O SPFILE pode ser backupeado usando o RMAN. Além disso, é possível gerar um PFILE a partir de um SPFILE, e vice-versa. Esta tarefa é importante e deve ser feita com frequência, para efeitos de backup.

Alert Log e Trace Log

Quando algum tipo de problema ocorre na instância, o Oracle grava mensagens de erro no Alert Log. No caso de processos background ou sessões de usuário a gravação é feita em trace log.

Os trace logs e também o alert log são gravados no diretório especificado pelo parâmetro BACKGROUND_DUMP_DEST.

Alguns eventos que são gravados no Alert Log:

STARTUP ou SHUTDOWN do banco de dados;

lista dos parâmetros de inicialização que são carregados com valores diferentes do padrão;

comandos ALTER DATABASE e comandos ALTER SYSTEM emitidos pelo DBA;

operações relacionadas aos tablespaces e aos respectivos datafiles;

condições de erro, como falta de espaço num tablespace, redo logs danificados,dentre quaisquer outras condições críticas.

Também são criados trace logs para sessões individuais dos usuários ou para conexões com o banco de dados. Esses trace logs estão localizados no diretório especificado pelo parâmetro USER_DUMP_DEST. Esses arquivos são criados em duas situações: quando ocorre algum tipo de erro em uma sessão do usuário (como um problema de privilégio, esgotamento de espaço, dentre outros); ou podem ser criados explicitamente com o comando:

ALTER SESSION SET SQL_TRACE=TRUE;

A informação de rastreamento é gerada para cada instrução SQL executada pelo usuário, o que pode ser útil para se ajustar a instrução SQL do usuário.

Backup Files

Os arquivos de backup podem se originar em algumas fontes, como os comandos de cópia do sistema operacional ou do Oracle RMAN. Se o DBA fizer um backup “a frio”, os arquivos de backup serão apenas cópias dos datafiles do sistema operacional, dos redo logs, dos controfiles, dos archive logs e de outros arquivos.

Além das cópias idênticas dos datafiles (padrão), o RMAN também pode gerar backups completos e incrementais dos datafiles, controlfiles, archive logs e spfiles em um formato especial, denominado backup sets, legível somente no RMAN.

Os backup sets geralmente são menores do que os arquivos originais de dados, pois o RMAN não copia os blocos não utilizados.

Estruturas de Memória


O Oracle utiliza a memória física do servidor para armazenar muitos itens para uma instância do Oracle.

Os executáveis do Oracle vão para a software code area.

A PGA (Program Global Area) é privativa para os processos de cada servidor e processos em segundo plano. Uma PGA é alocada para cada processo de sessão do usuário ou do servidor.

A SGA é a área de dados alocada para uma instância do Oracle.

Veremos um pouco sobre cada uma destas estruturas com mais detalhes abaixo.

SGA – System Global Area

A SGA é um grupo de estruturas compartilhadas de memória para uma instância do Oracle, compartilhada pelos usuários da instância do banco de dados. Quando uma instância é inicializada, a memória é alocada para a SGA com base nos valores especificados no parameter file.

Alguns dos parâmetros que controlam tamanho das estruturas da SGA são dinâmicos, porém, se o parâmetro SGA_MAX_SIZE for definido, o tamanho total de todas as áreas da SGA não irá exceder o valor de SGA_MAX_SIZE.

Se o SGA_MAX_SIZE não for especificado, o parâmetro SGA_TARGET é verificado, e caso o mesmo seja definido com um valor válido, o Oracle ajustará automaticamente o tamanho dos componentes da SGA, de modo que o total da memória alocada seja igual ao SGA_TARGET. Este parâmetro é dinâmico e pode ser alterado quando a instância estiver em execução. O parâmetro MEMORY_TARGET (a partir do 11g) equilibra toda a memória disponível para o Oracle entre a SGA e a PGA para otimizar o desempenho.

A memória na SGA é alocada em unidades de grânulos;

Um grânulo pode ter 4 ou 16 MB, dependendo do tamanho total da SGA;

Se a SGA for menor ou igual a 128 MB, um grânulo terá 4 MB; caso contrário terá 16 MB.

Buffer Cache

O Database Buffer Cache armazena os blocos de dados do disco que foram recentemente lidos para atender um comando SELECT ou que contêm blocos modificados ou adicionados por uma instrução DML.

A área de memória na SGA que armazena esses blocos é dinâmica;

Cada tamanho de bloco diferente (em casos de bases onde há tablespaces com blocos de tamanhos diferentes) exige um buffer cache próprio;

Os valores dos parâmetros DB_CACHE_SIZE e DB_nK_CACHE_SIZE podem ser alterados dinamicamente, sem reinicializar a instância;

O Oracle pode utilizar dois caches adicionais com o mesmo tamanho do bloco padrão: o KEEP buffer pool e o RECYCLE buffer pool;

Quando uma tabela é criada, é possível especificar o pool no qual residirão os blocos de dados da tabela por meio da BUFFER_POOL_KEEP ou BUFFER_POOL_RECYCLE dentro da cláusula STORAGE;

Para as tabelas mais utilizadas durante o dia, seria vantajoso colocá-las no KEEP buffer pool para minimizar o I/O necessário para recuperar os blocos contidos nas tabelas.

shared pool

É dimensionado pelo SHARED_POOL_SIZE. Contém dois subcaches importantes: Library Cache e o Data Dictionary Cache.

SHARED_POOL_SIZE é dinâmico, pode ser redimensionado;

Ao realizar o redimensionamento, deve ser respeitado o tamanho total da SGA que deve ser menor que SGA_MAX_SIZE ou SGA_TARGET;

O Library Cache armazena informações sobre as instruções SQL e PL/SQL executadas no banco de dados. Diversos usuários diferentes podem compartilhar a mesma instrução SQL nesta área;

Além da instrução SQL, a Library Cache armazena também o seu plano de execução;

Na segunda vez que uma instrução SQL idêntica for executada, pelo mesmo ou por outro usuário, o plano de execução já estará calculado, o que reduz o tempo de execução do comando SQL;

Se o tamanho da library cache for muito pequeno, os planos de execução podem ser descarregados do cache (dando lugar para novos planos), exigindo assim recarregamentos frequentes das instruções SQL. Neste caso, recomenda-se aumentar o tamanho da library cache;

O dicionário de dados é um conjunto de tabelas internas do banco de dados, pertencentes aos schemas SYS e SYSTEM, que contêm os metadados sobre o banco de dados, suas estruturas e privilégios e as funções dos usuários do banco de dados;

O Data Dictionary Cache armazena um subconjunto das colunas das tabelas do dicionário de dados depois que forem lidas pela primeira vez para o buffer cache;

Os blocos de dados das tabelas do dicionário de dados são sempre usados para ajudar no processamento das consultas dos usuários e de outros comandos DML;

Se o Data Dictionary Cache for muito pequeno, as solicitações de informações do dicionário de dados acarretarão I/O. Essas solicitações do dicionário de dados associadas à I/O são conhecidas como recursive calls e devem ser evitadas dimensionando corretamente o Data Dictionary Cache.

Redo Log Buffer

O Redo Log Buffer armazena as alterações mais recentes efetuadas nos blocos de dados. Essas alterações passam pelo Redo Log Buffer antes de ir para os Redo Log Files.

Esta gravação dos registros do Redo Log Buffer para o Redo Log File acontece quando:

um terço do redo log buffer estiver preenchido;

a cada 3 segundos;

ocorrer um commit;

ocorrer um checkpoint.

Uma trasação com commit não é considerada concluída até que as entradas de redo log tenham sido gravadas com êxito nos redo log files.

Large Pool

O Large Pool é uma área opcional da SGA. É utilizada em transações com mais de um banco de dados envolvidos, buffers de mensagens para processos executando consultas paralelas, e operações paralelas de backup e recovery do RMAN.

A Large Pool disponibiliza grandes blocos de memória para operações que precisam alocá-los de uma só vez. O parâmetro LARGE_POOL_SIZE controla seu tamanho, e é um parâmetro dinâmico desde a versão 9iR2.

Java Pool

Utilizado pela Oracle JVM (Java Virtual Machine) para todos os códigos e dados Java em uma user session. Códigos e dados Java armazenados no Java Pool são semelhantes ao armazenamento de código SQL e PL/SQL na shared pool.

Streams Pool

Dimensionado pelo parâmetro STREAMS_POOL_SIZE. Guarda dados e estruturas de controle para o Oracle Streams. O Oracle Streams gerencia o compartilhamento de dados e eventos em um ambiente distribuído. Se STREAMS_POOL_SIZE for zero, a memória utilizada nas operações do Streams será alocada a partir da Shared Pool e poderá usar até 10% da Shared Pool.

PGA – Program Global Area

PGA é uma área de memória que aloca seções dinâmicas, de modo privado, para um conjunto de processos de conexão. Sua configuração depende da configuraçãoda conexão do banco de dados: servidor compartilhado (shared server) ou servidor dedicado (dedicated server).

Em um shared server, diversos usuários compartilham uma conexão com o banco de dados, minimizando o uso da memória no servidor, mas possivelmente afetando o tempo de resposta às solicitações do usuário. Neste caso a SGA guarda informações persistentes da sessão do usuário. Este ambiente é perfeito para um número muito grande de conexões simultâneas com o banco de dados, porém com solicitações raras ou de curta duração.

Em um dedicated server, cada processo de usuário estabelece uma conexão própria com o banco de dados. A PGA contém a memória da sessão para essa configuração, e também engloba uma área de classificação utilizada sempre que a solicitação de um usuário exigir uma operação de SORT, mesclagem de bitmaps ou hash join.

O parâmetro PGA_AGGREGATE_TARGET em conjunto com o WORKAREA_SIZE_POLICY podem facilitar a administração do sistema, permitindo que o DBA defina um tamanho total para todas as áreas de trabalho e deixando o Oracle gerenciar e alocar a memória entre todos os processos de usuário.

Software Code Area


Armazenam os arquivos executáveis do Oracle, em execução como parte de uma instância do Oracle. Essas áreas de código têm natureza estática e só mudam quando é instalado um novo release do software.

Geralmente estão localizadas em uma área privilegiada da memória, isoladamente dos outros programas do usuário. Ele é read-only, obviamente, e pode ser instalado como compartilhável ou não compartilhável. Instalar o software code do Oracle como compartilhável economiza memória quando várias instâncias do Oracle estão em execução no mesmo servidor e no mesmo nível de release de software.

Background Process

Quando uma instância é inicializada, vários processos em segundo plano são iniciados. Um Background Process é um bloco de código executável responsável por alguma tarefa específica.

São assim chamados por trabalharem “nos bastidores”, diferente de uma sessão do SQL*Plus por exemplo. Juntos, a SGA e os background process formam uma instância do Oracle.

Abaixo, os background process:

SMON

System Monitor. Executa o processo de recovery durante um startup caso tenha ocorrido um shutdown abort ou alguma outra falha, aplicando as entradas existentes nos arquivos de redo log;

Expurga segmentos temporários durante a reinicialização da instância;

Faz a “junção” do espaço livre das tablespaces gerenciadas por dicionário (algo raro e possivelmente inexistente na grande maioria dos bancos em versão 11g).

PMON

Process Monitor. Faz o trabalho de “limpeza” quando cai a conexão de um usuário ou se um processo de usuário falhar. Ele limpa o database buffer cache e todos os outros recursos qua a conexão estava utilizando. Ao detectar que a conexão não existe mais, o PMON executa as seguintes tarefas:

Aplica rollback na transação que estava em andamento;

Marca os blocos da transação como disponíveis no buffer cache;

Remove os locks (bloqueios) sobre as linhas afetadas na tabela;

Remove o ID do processo desconectado da lista de processos ativos.

DBWn

O Database Writer (conhecido como DBWR nas versões anteriores) grava os blocos de dados novos ou modificados (conhecidos como dirty block, ou blocos sujos) existentes no buffer cache para os datafiles;

Usa o algoritmo LRU (Least Recently Used), escrevendo primeiro os blocos mais antigos e menos ativos;

É possível inicializar até 20 processos DBWn, do DBW0 ao DBW9 e do DBWa ao DBWj;

O número de processos é controlado pelo parâmetro DB_WRITER_PROCESSES.

LGWR

O Log Writer é responsável pelo gerenciamento do redo log buffer;

É um dos processos mais ativos de uma instância, com intensa atividade de DML;

Uma transação não é considerada concluída até que o LGWR grave com êxito as informações de redo, incluindo o registro de commit, nos redo log files;

Os dirty blocks do buffer cache não podem ser gravados nos datafiles pelo DBWn antes que o LGWR grave as informações de redo.

ARCn

Se o banco estiver em modo archivelog, o archiver process copiará os redo logs em um ou mais diretórios de destino, dispositivos ou localizações da rede sempre que um redo log ficar totalmente preenchido e as informações de redo começarem a preencher o redo log seguinte, em sequência.

Este processo de arquivamento precisa terminar antes que o redo log preenchido seja necessário novamente, caso contrário ocorrerão sérios problemas de desempenho – as transações não serão concluídas até que as entradas sejam gravadas no redo log, mas os redo log files não estarão prontos para aceitar novas entradas porque ainda está sendo gravado no local do arquivamento.

Possíveis soluções para este problema:

Aumentar o tamanho dos redo log files;

aumentar o número de grupos de redo log;

aumentar a quantidade de processos ARCn.

Podem ser inicializados até 10 processos ARCn para cada instância, aumentando o valor do parâmetro de inicialização LOG_ARCHIVE_MAX_PROCESSES.

CKPT

O Checkpoint Process ajuda a reduzir o tempo necessário para a recuperação da instância. Durante um checkpoint, o CKPT atualiza o cabeçalho do controlfile e os datafiles para refletir o último SCN (System Change Number) bem-sucedido. Um checkpoint ocorre automaticamente sempre que um redo log file é preenchido.

Os processos DBWn gravam os dirty blocks para antecipar o checkpoint a partir do qual a recuperação da instância pode iniciar, reduzindo o MTTR (Mean Time to Recovery).

RECO

O Recoverer Process trata das falhas das transações distribuídas. Se uma transação alterar duas tabelas de bancos de dados diferentes, e a conexão de rede entre estes bancos falhar antes da atualização de um dos bancos, o RECO forçará um rollback na trasação.


- Referência Bibliográfica


Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – http://www.bookman.com.br

Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.

Fonte: http://certificacaobd.com.br/2012/04/18/ocp-11g-capitulo-1-resumo-arquitetura-e-asm-parte-1/
Milton Bastos.

OCP 11g – Capítulo 9: Configurando e Usando Flashback

Restaurar tabelas eliminadas a partir da lixeira
     
      Flashback Drop usa a lixeira para recuperar as tabelas eliminadas.
      A lixeira (recycle bin) é uma tabela do dicionário de dados que rastreia os objetos eliminados.
      É possível restaurar as versões atual ou anterior das tabelas eliminadas a partir da lixeira.
      Quando você elimina um objeto com a lixeira ativada, o espaço alocado para o objeto eliminado e para todos os objetos associados (como índices) passa a constar imediatamente na view do dicionário de dados DBA_FREE_SPACE.
      Quando uma tabela é eliminada, a tabela e seus objetos dependentes são renomeadas com um nome atribuído pelo sistema, usando um formato BIN$unique_id$version.
      Para consultar a lixeira, você pode utilizar a view do dicionário de dados USER_RECYCLEBIN. RECYCLEBIN é um sinônimo global para USER_RECYCLEBIN.
      A view do dicionário de dados USER_RECYCLEBIN tem as mesmas colunas da view DBA_RECYCLEBIN, exceto que a USER_RECYCLEBIN não possui a coluna owner.
      Para restaurar uma tabela da lixeira, use o comando FLASHBACK TABLE ... TO BEFORE DROP.
      Se você tentar restaurar uma tabela que foi recriada depois de sua eliminação, receberá um erro, a menos que você inclua a cláusula RENAME TO para atribuir um novo nome à tabela restaurada.
      O espaço na lixeira e, por extensão, o espaço no tablespace contendo a lixeira são gerenciados automaticamente pelo Oracle.
      Todos os objetos eliminados continuam disponíveis para recuperação na lixeira, desde que os novos objetos não necessitem do espaço ocupado pelos objetos eliminados.
      Você pode emitir o comando PURGE para remover manualmente as tabelas da lixeira.
      Quando um objeto reside na lixeira, você também pode utilizar a instrução SELECT para acessar a tabela eliminada, que continuará constando nas views do dicionário de dados DBA_TABLES, DBA_OBJECTS e DBA_SEGMENTS.

Executar um Flashback Query

      O Flashback Query permite exibir uma ou mais linhas de uma tabela em um tempo no passado.
      Para garantir o êxito das operações de flashback ou das consultas de longa execução às custas da atividade DML, você deve especificar RETENTION GUARANTEE para o tablespace de undo.
      É possível verificar o status da retenção de um tablespace de undo consultando a view do dicionário de dados DBA_TABLESPACES.
      O Flashback Query usa a cláusula AS OF para especificar o ponto anterior no tempo como um timestamp ou um SCN.
      O Flashback Version Query, outro recurso de flashback, propicia um nível com mais detalhamento do que a consulta com AS OF (Flashback Query).
      O Flashback Version Query usa a cláusula VERSIONS BETWEEN para especificar um intervalo de SCNs ou timestamps para análise de uma tabela específica.

Usar o Flashback Transaction

      A view do dicionário de dados FLASHBACK_TRANSACTION_QUERY tem todas as informações de que você necessita para identificar o código SQL necessário para reverter uma transação.
      Para utilizar o Flashback Transaction Query, você deve ativar o registro em log adicional para o fluxo de redo log. Esses são os mesmos dados que o Log Miner utiliza, embora em outra interface.
      Você deve conceder permissões sobre a package DBMS_FLASHBACK, assim como o privilégio SELECT ANY TRANSACTION aos usuários que usarão o Flashback Transaction Query,
      A coluna UNDO_SQL do FLASHBACK_TRANSACTION_QUERY contém o código SQL que pode ser utilizado para reverter o efeito de uma transação.
      O Enterprise Manager (EM) fornece uma GUI fácil de usar como front-end para a procedure DBMS_FLASHBACK.TRANSACTION_BLACKOUT
      As quatro opções de reversão de transações são: CASCADE, NOCASCADE, NOCASCADE_FORCE e NONCONFLICT_ONLY.

Executar operações de Flashback Table


      O recurso Flashback Table do Oracle não somente restaura o estado das linhas de uma tabela a partir de um ponto do tempo no passado, como também restaura os índices, os triggers e as restrições da tabela enquanto o banco de dados estiver online.
      O Flashback Table é preferível aos outros métodos de flashback se o escopo dos erros do usuário for pequeno e limitado a uma ou poucas tabelas.
      O Flashback Table é executado localmente, com o banco de dados online, revertendo as alterações feitas na tabela e em todos os respectivos objetos dependentes, como os índices.
      Para executar o Flashback Table, o usuário deve ter o privilégio FLASHBACK ANY TABLE, ou o privilégio de objeto FLASHBACK sobre uma tabela específica.
      Para utilizar o Flashback Table sobre uma ou mais tabelas, você deve ativar a movimentação de linhas antes de executar a operação de Flashback, embora não seja necessário que essa movimentação esteja em vigor quando ocorrer o erro do usuário.
      As operações de Flashback Table não podem englobar as operações DDL, como adição ou eliminação de uma coluna.

Configurar e utilizar um Flashback DataArchive

      Um Flashback Data Archive retém os dados históricos de uma ou mais tabelas por um período de retenção.
      Para ativar o Flashback Data Archive, crie uma ou mais áreas de repositório (uma das quais pode ser a área padrão), atribua um período de retenção padrão para os objetos marque para rastreamento as tabelas adequadas.
      Um Flashback Data Archive atua basicamente como um tablespace de undo. Entretanto, um Flashback Data Archive registra apenas as instruções UPDATE e DELETE, não as instruções INSERT.
      Você pode acessar dados em um Flashback Data Archive exatamente como você faz com o Flashback Query, usando a cláusula AS OF em uma instrução SELECT.
      Crie um ou mais Flashback Data Archives nos tablespaces já existentes emitindo o comando CREATE FLASHBACK ARCHIVE.
      As views do dicionário de dados que respaldam os Flashback Data Archives são: DBA_FLASHBACK_ARCHIVE e DBA_FLASHBACK_ARCHIVE_TS.
      A view DBA_FLASHBACK_ARCHIVE_TABLES rastreia as tabelas ativadas para o flashback archive.
      Para criar ou modificar os Flashback Data Archives, o usuário deve ter o privilégio de sistema FLASHBACK ARCHIVE ADMINISTER.
      Atribua uma tabela a um arquivo durante a criação da tabela, usando a sintaxe padrão CREATE TABLE com a inclusão da cláusula FLASHBACK ARCHIVE, ou posteriormente, com o comando ALTER TABLE.

Configurar, monitorar o Flashback Database e executar operações de Flashback Database

     
      O Flashback Database usa o comando FLASHBACK DATABASE para retornar um banco de dados a um tempo no passado ou a um SCN, propiciando uma alternativa rápida para a execução da recuperação incompleta do banco de dados.
      Quando você ativar o recurso Flashback Database, as imagens anteriores dos blocos modificados serão salvas na área de recuperação flash como logs de Flashback Database.
      Os logs na área de recuperação flash são reutilizados de forma circular.
      Configurar corretamente o tamanho da área de recuperação flash garante espaço suficiente disponível para os logs do Flashback Database e para todas as demais informações contidas nessa área.
      Defina o parâmetro de inicialização DB_FLASHBACK_RETENTION_TARGET com o limite máximo (em minutos) para a sua janela de recuperação utilizável; isso é uma meta, não uma garantia.
      Você pode utilizar o comando FLASHBACK DATABASE no RMAN ou no prompt SQL>.
      É possível utilizar a cláusula TO SCN ou TO TIMESTAMP para definir o ponto de flashback do banco de dados inteiro, além de um ponto de restauração garantido.
      Você pode usar a pseudocoluna ORA_ROWSCN para determinada linha da tabela para ver os SCNs das modificações mais recentes efetuadas na linha de uma tabela.
      Se não existirem dados suficientes nos archive logs e na área de flashback, você deverá aplicar os métodos tradicionais de recuperação de banco de dados para recuperar os dados.
      Para desativar o Flashback Database, execute o comando ALTER DATABASE FLASHBACK OFF quando o banco estiver montado e não aberto.
      Por padrão, todos os tablespaces participarão em uma operação de Flashback Database, a menos que você modifique o atributo FLASHBACK para OFF no momento da criação do tablespace, ou posteriormente, usando o comando ALTER TABLESPACE.
      Um ponto de restauração garantido é parecido com um ponto de restauração comum, uma vez que pode ser utilizado como um alias para um SCN durante uma operação de recuperação.
      Um ponto de restauração garantido é diferente, no sentido de que ele não é obsoletado do controlfile e deve ser explicitamente eliminado.
      Criar um ponto de restauração garantido com um registro em log de flashback ativado assegura a retenção de logs de flashback na área de recuperação flash, para permitir a reversão do banco de dados até um ponto posterior à criação do ponto de restauração garantido.
      Você pode determinar até onde é possível fazer o flashback do banco de dados consultando a view V$FLASHBACK_DATABASE_LOG.
      É possível utilizar a view V$FLASHBACK_DATABASE_STAT para monitorar a taxa horária de geração de dados de flashback.


- Referência Bibliográfica

Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – http://www.bookman.com.br

Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.

Fonte: http://certificacaobd.com.br/2012/04/18/ocp-11g-capitulo-1-resumo-arquitetura-e-asm-parte-1/
Milton Bastos

OCP 11g – Capítulo 8: Monitorando e Ajustando o RMAN

Monitorar sessões e jobs do RMAN

Você pode juntar as views V$SESSION e V$PROCESS para identificar os processos do sistema operacional associados a cada canal do RMAN.
O comando SET COMMAND ID do RMAN ajuda a distinguir os processos dos diferentes jobs de backup na view V$SESSION.
Use a view V$SESSION_LONGOPS para monitorar o status de jobs do RMAN executados por mais de 6 segundos.
A view V$SESSION_LONGOPS coném as linhas de detalhes e de agregação de cada job do RMAN.
Você deve definir o parâmetro de inicialização STATISTICS_LEVEL com TYPICAL ou ALL para que o RMAN registre as informações sobre o status dos jobs na view V$SESSION_LONGOPS.
As informações de depuração do RMAN constam na saída da linha de comando, nos trace files específicos do RMAN, no alert log, nos trace files do Oracle e nos trace files específicos dos fornecedores.
Inclua a opção debug na linha de comando do sistema operacional para ativar a depuração e, opcionalmente, especificar um arquivo que armazenará a saída da depuração.
Use o comando DEBUG ON ou DEBUG OFF para ativar ou desativar a depuração do RMAN dentro da sessão do RMAN.

Ajustar o RMAN

Os jobs de backup ou recovery do RMAN executam tarefas em três fases principais: leitura, cópia e gravação.
A fase de cópia no RMAN é subdividida em três subfases> validação, compressão e criptografia.
O paralelismo (alocação de vários canais) pode melhorar o desempenho do backup.
É possível alocar até 255 canais por sessão do RMAN, e cada canal pode ler até 64 arquivos de dados simultaneamente.
A multiplexação é controlada basicamente pelos parâmetros FILESPERSET e MAXOPENFILES.
Para calcular o nível de multiplexação, use a seguinte fórmula: min(MAXOPENFILES, min(FILESPERSET, files_per_channel))
Você pode ajustar os canais do RMAN por meio dos parâmetros MAXPIECESIZE, RATE e MAXOPENFILES.
Ajuste o comando BAKCUP através dos parâmetros MAXPIECESIZE, FILESPERSET, MAXOPENFILES e BACKUP DURATION.
O parâmetro BACKUP DURATION do comando BACKUP pode ser definido com MINIMIZE TIME para executar o backup o mais rapidamente possível, ou com MINIMIZE LOAD para reduzir a demanda por I/O no banco de dados.
É possível configurar o parâmetro de inicialização LARGE_POOL_SIZE para reduzir a contenção no shared pool para os backups do RMAN.

Configurar o RMAN para I/O assíncrono

As operações síncronas de backup devem aguardar o término para iniciar outra solicitação de I/O. A soperações assíncronas de backup não precisam esperar.
Defina o parâmetro de inicialização BACKUP_TAPE_IO_SLAVES com TRUE para configurar backups em fita para operações assíncronas.
A definição do parâmetro de inicialização DBWR_IO_SLAVES aloca quatro processos auxiliares de I/O de disco de backup para simular operações assíncronas de I/O do RMAN.
Use a view dinâmica V$BACKUP_ASYNC_IO para monitorar as operações assíncronas do RMAN.
A proporção entre LONG_WAITS e IO_COUNT na view V$BACKUP_ASYNC_IO deve ser a menor possivel, para reduzir ou eliminar gargalos.
Se a coluna SHORT_WAIT_TIME_TOTAL ou LONG_WAIT_TIME_TOTAL da view V$BACKUP_ASYNC_IO não for zero, o arquivo associado deverá ser ajustado.
Use a view dinâmica V$BACKUP_SYNC_IO para identificar os gargalos nas operações síncronas de backup ou recovery do RMAN.
A coluna DISCRETE_BYTES_PER_SECOND na view V$BACKUP_SYNC_IO pode ser comparada com a taxa máxima de um dispositivo de saída de fita para identificar oportunidades de ajuste.


- Referência Bibliográfica


Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – http://www.bookman.com.br

Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.

Fonte: http://certificacaobd.com.br/2012/04/18/ocp-11g-capitulo-1-resumo-arquitetura-e-asm-parte-1/
Milton Bastos

Capítulo 7: Recursos diversos do RMAN

Este resumo cobre 2 assuntos muito importantes: a duplicação de um banco de dados através do RMAN e também o TSPITR (Tablespace Point-in-time Recovery). Estes tópicos parecem não estar relacionados, mas eles têm um aspecto em comum: ambos precisam da criação de uma instância auxiliar para executar a tarefa solicitada. Após duplicar um banco de dados, o RMAN mantém a instância temporária e o banco de dados; ao contrário, no caso da TSPITR, o RMAN elimina a instância auxiliar após a operação de recovery.

A maior parte da duplicação de um banco de dados usando o RMAN é automatizada, exceto em algumas etapas de configuração manuais. Essas etapas incluem tarefas como criar um arquivo de senhas, configurar a conectividade de rede, e criar um arquivo de parâmetros de inicialização baseado em texto contendo apenas alguns parâmetros obrigatórios, como o DB_NAME. A especificação de outros parâmetros de inicialização depende de você especificar explicitamente DB_BLOCK_SIZE no banco de dados de origem e do mapeamento de nome de caminho necessário para especificar corretamente as localizações dos datafiles, controlfiles, e redo log files. Usar o Enterprise Manager para duplicar um banco de dados é um método mais fácil, mas talvez não propicie a personalização disponível com o uso dos comandos de linha de comando do RMAN e SQL.

A segunda metade do capítulo abordou a TSPITR. Estão disponíveis diversas técnicas de recuperação. A técnica a ser aplicada vai depender do tipo de dano ocorrido no banco de dados. Se esse dano estiver limitado às tabelas de um único tablespace com pouca ou nenhuma dependência com objetos de outros, a TSPITR provavelmente será sua melhor opção. Além disso, o banco de dados e todos os outros tablespaces continuam disponíveis para os usuários durante a operação da TSPITR.

Criar um banco de dados duplicado no RMAN

Quando você duplica um banco de dados, o banco de dados de origem é copiado para o banco de dados duplicado.
O banco de dados de origem também é conhecido como banco de dados target.
O banco de dados duplicado também é conhecido como banco de dados auxiliar.
A preparação para criar um banco de dados duplicado inclui a criação de um arquivo de senhas, a verificação da conectividade da rede e a criação do arquivo de parâmetros de inicialização para a instância auxiliar.
Você deve, no mínimo, especificar o parâmetro DB_NAME no arquivo de parâmetros inicialização da instância auxiliar. Especifique também o parâmetro DB_DLOCK_SIZE se ele estiver definido explicitamente no banco de dados de destino.
O parâmetro de inicialização DB_FILE_NAME_CONVERT especifica o mapeamento do sistema de arquivos para nomes de datafiles e arquivos temporários.
O parâmetro de inicialização LOG_FILE_NAME_CONVERT especifica o mapeamento do sistema de arquivos para os redo log files.
O parâmetro CONTROL_FILES especifica os novos nomes para todos os controlfiles, a menos que você esteja utilizando OMF’s (Oracle Managed Files), uma vez que o OMF nomeará os arquivos para você.
O comando do RMAN para executar a duplicação do database é DUPLICATE TARGET DATABASE.
É possível especificar FROM ACTIVE DATABASE no comando DUPLICATE para criar a cópia a partir de um banco de dados online, em vez de um backup de banco de dados.
O banco de dados duplicado tem um novo DBID, mesmo que ele tenha o mesmo nome do banco de dados de origem.

Usar um banco de dados duplicado


Um banco de dados duplicado pode ser utilizado para testar os procedimentos de backup e recovery, sem afetar a disponibilidade do banco de dados de origem.
Você pode usar um banco de dados duplicado para testar um upgrade do banco de dados ou o desempenho de upgrades dos aplicativos.
Você pode exportar uma ou mais tabelas de um banco de dados duplicado e importar novamente no banco de dados de produção como um método de recovery secundário.

Identificar as situações que exigem TSPITR

O TSPITR é útil quando uma ou mais tabelas danificadas ou ausentes são isoladas em um único tablespace e têm dependências mínimas ou nenhuma dependência com objetos existentes em outros tablespaces.
Você pode utilizar o TSPITR quando as mudanças por DDL impedirem o uso de Flashback Table para recuperar os objetos.
Não é possível utilizar a TSPITR para recuperar um tablespace eliminado ou recuperar um tablespace renomeado até um ponto no tempo anterior à sua renomeação.

Fazer uma TSPITR automatizada

O Target Time é o ponto no tempo até o qual o tablespace será recuperado.
O Recovery Set é um grupo de datafiles contendo os tablespaces a serem recuperados.
O conjunto auxiliar é um conjunto de outros datafiles necessários para recuperar aqueles contidos no Recovery Set, como o tablespace SYSTEM.
O destino auxiliar é uma área de trabalho temporária usada pelo RMAN para armazenar conjuntos auxiliares de arquivos, arquivos de log e uma cópia do controlfile.
O RMAN elimina a instância auxiliar e exclui todos os arquivos auxiliares por ocasião do término da TSPITR.
Use a view do dicionário de dados TS_PITR_CHECK para descobrir as dependências existentes entre os objetos contidos no tablespace a ser recuperado e os objetos em outros tablespaces.
Use a view do dicionário de dados TS_PITR_OBJECTS_TO_BE_DROPPED para conhecer os objetos que você perderá após a TSPITR.
Execute uma TSPITR no RMAN usando o comando RECOVER TABLESPACE com as cláusulas UNTIL TIME e AUXILIARY DESTINATION.
Após o término da TSPITR, você deve fazer o backup do tablespace recuperado e restaurá-lo online.

  - Referência Bibliográfica

Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – http://www.bookman.com.br

Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.

Fonte: http://certificacaobd.com.br/2012/04/18/ocp-11g-capitulo-1-resumo-arquitetura-e-asm-parte-1/
Milton Bastos

Capítulo 6: Backup e Recovery gerenciados pelo usuário

Fazer um recovery a partir de um arquivo temporário perdido

Um arquivo temporário pode ser recuperado com o banco de dados aberto.
O impacto de um arquivo temporário perdido é percebdo quando os usuários tentam ordenar grandes conjuntos de resultados.
Quando um arquivo temporário desaparece, é possível recriá-lo na localização original ou informar uma nova localização.
Se o banco de dados for inicializado sem os arquivos temporários, ele os criará na localização especificada no controlfile.

Fazer um recovery a partir de um grupo de redo logs perdido

Um grupo de redo logs pode ter seis status: CURRENT, ACTIVE, INACTIVE, UNUSED, CLEARING ou CLEARING_CURRENT. Os status mais comuns são CURRENT, ACTIVE e INACTIVE.
É possível usar a view dinâmica de desempenho V$LOG para consultar o status de cada grupo de redo logs.
Se um membro de um grupo de redo logs for danificado ou desaparecer, o processo LGWR (Log Writer) continuará gravando no membro não-danificado, e não ocorrerá qualquer perda de dados ou interrupção de serviço.
A view dinâmica de desempenho V$LOGFILE informa o status de cada membro individual de cada grupo de arquivos de log.
Se o status de um membro de um grupo de arquivo de log for INVALID na view V$LOGFILE, ele está danificado ou indisponível e deverá ser recriado.
Muito provavelmente, a perda de um grupo de arquivos de log com o status INACTIVE não acarretará a perda de transações com commit, desde que os outros membros desse grupo permaneçam intactos.
A perda de um grupo de arquivos de redo log com um status ACTIVE não acarretará a perda das transações com commit se você conseguir executar com êxito o comando ALTER SYSTEM CHECKPOINT. Se o checkpoint falhar, você deverá fazer uma recuperação incompleta.
A perda de um grupo de arquivos de redo log com o status CURRENT acarretará uma falha na instância, e você deverá fazer uma recuperação incopleta.

Fazer um recovery a partir da perda do arquivo de senhas

A perda de um arquivo de senhas impede que os DBA’s se conectem com uma instância aberta ou fechada com o privilégio SYSDBA, SYSOPER ou SYSASM.
Use um arquivo de senhas se estiver estabelecendo conexão remota e a conexão não for segura.
Conectar-se usando o privilégio SYSDBA ou SYSASM estabelece conexão com o banco de dados como o usuário SYS. O privilégio SYSOPER conecta como PUBLIC.
Use o comando orapwd em um prompt do sistema operacional para recriar o arquivo de senhas,
A localização padrão do arquivo de senhas é $ORACLE_HOME/dbs no Unix ou Linux, e %ORACLE_HOME%\database no Windows.
A view dinâmica de desempenho V$PWFILE_USERS lista todos os usuários do banco de dados que possuem os privilégios SYSDBA, SYSOPER ou SYSASM.

Fazer um recovery incompleto do banco de dados, gerenciado pelo usuário

Se ocorrer uma falha de mídia em seu banco de dados, em geral você irá preferir usar uma recuperação completa para restaurá-lo ao estado que se encontrava antes da falha, o que inclui todas as transações com commit.
Em uma recuperação de banco de dados aberto ou fechado, é possível recuperar o banco de dados inteiro de uma só vez, um tablespace de cada vez ou um datafile por vez.
Você pode consultar a view dinâmica de desempenho V$RECOVER_FILE para saber quais arquivos necessitam de recuperação de mídia, e a view V$RECOVER_LOG para conhecer os archivelogs necessários para recuperar os datafiles restaurados no recovery completo do banco de dados.
Faça um recovery completo, gerenciado pelo usuário, depois que o banco de dados for restaurado no modo MOUNT.
Todos os archivelogs necessários para recuperar os datafiles restaurados devem estar disponíveis na localização padrão a fim de automatizar o processo de recovery com a cláusula AUTOMATIC do comando RECOVER.
Se os archivelogs necessários para o recovery residem em diversas localizações, você poderá especificá-las manualmente durante o processo de recuperação quando você não incluir a palavra-chave AUTOMATIC.
Você pode fazer o recovery completo de um ou mais tablespaces danificados com o banco de dados aberto, colocando os tablespaces no modo offline com o comando ALTER TABLESPACE ... OFFLINE TEMPORARY.
Para recuperar um tablespace enquanto estiver no modo offline e o restante do banco estiver online, use o comando RECOVER AUTOMATIC TABLESPACE ... depois de restaurar os datafiles do tablespace a partir da localização do backup.

Fazer backups gerenciados pelo usuário e pelo servidor


Se você não estiver executando no modo ARCHIVELOG, deverá desligar o banco de dados para fazer um backup usando os comandos do sistema operacional.
No modo ARCHIVELOG, você pode colocar um tablespace individual ou um banco de dados inteiro no modo BEGIN BACKUP. A partir de então, você pode copiar os datafiles para um diretório de backup. Em seguida, você pode retirar o banco de dados do modo de backup. Em seguida, você pode retirar o banco de dados do modo de backup com END BACKUP.
Com o banco de dados aberto, é possível consultar as views dinâmicas de desempenho V$DATAFILE e V$CONTROLFILE para identificar as localizações de todos os datafiles e de todas as cópias do controlfile.
Ao fazer um backup com o banco de dados fechado, esse backup é considerado consistente porque os SCN’s de todos os datafiles estão sincronizados; todos os arquivos são congelados no tempo.
Para fazer o backup dos datafiles para um tablespace individual, use a view do dicionário de dados DBA_DATA_FILES para ver a associação entre os tablespaces e os nomes dos datafiles.
O banco de dados não será desligado se algum tablespace estiver no modo de backup.

Identificar a necessidade do modo de backup

Copiar um datafile com um comando do sistema operacional enquanto o processo DBWR estiver atualizando o bloco pode acarretar um bloco fraturado.
Se você utilizar o RMAN para fazer backup dos datafiles, ele repetirá automaticamente a leitura do bloco várias vezes até considerá-lo consistente.
Para o ALTER DATABASE BEGIN BACKUP ou ALTER TABLESPACE ... BEGIN BACKUP, o Oracle gera redo adicional (a imagem anterior do bloco) para o banco de dados ou para o tablespace individual até você retirar o banco de dados ou o tablespace do modo de backup.

Fazer backup e recovery de um controlfile

Para fazer o backup do controlfile com o banco de dados aberto, use dois comandos SQL diferentes:
ALTER DATABASE BACKUP CONTROLFILE TO e
ALTER DATABASE BACKUP CONTROLFILE TO TRACE.
ALTER DATABASE BACKUP CONTROLFILE TO cria uma cópia binária exata do controlfile na localização especificada.
ALTER DATABASE BACKUP CONTROLFILE TO TRACE gera um script editável que recria o controlfile no diretório $ORACLE_BASE/diag/rdbms///trace.
A perda de todas as cópias do controlfile não acarreta a perda de quaisquer transações com commit se você tiver uma cópia de backup recente do controlfile e os datafiles e redo logs estiverem intactos.
Não é necessário abrir o banco de dados com RESETLOGS após restaurar o controlfile se você criar manualmente o controlfile de substituição usando CREATE CONTROLFILE, ou se você usar uma versão do script do controlfile criada com ALTER DATABASE BACKUP CONTROLFILE TO TRACE.


- Referência Bibliográfica


Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – http://www.bookman.com.br

Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.

Fonte: http://certificacaobd.com.br/2012/04/18/ocp-11g-capitulo-1-resumo-arquitetura-e-asm-parte-1/
Milton Bastos

OCP 11g – Capítulo 5: Recuperação usando os Backups do RMAN

Recuperar datafile usando RMAN

Use os comandos RESTORE e RECOVER do RMAN para um recovery completo a partir de uma perda de datafile.
Os datafiles dos tablespaces SYSTEM e UNDO são críticos.
Ao restaurar e recuperar um datafile crítico, o banco de dados deve estar em modo MOUNT.
Você pode recuperar totalmente um datafile se o banco estiver em modo ARCHIVELOG.

Recuperação incompleta

Use pontos de restauração para recuperar um banco de dados para um SCN ou um momento específico no passado.
Use CREATE RESTORE POINT para criar um ponto de restauração.
Você deve abrir o banco de dados com RESETLOGS se você fizer uma recuperação incompleta.
Recuperar usando os backups atualizados no modo incremental
É possível recuperar image copies com os backups incrementais de nível 1 mais recentes.
O RMAN determina automaticamente a melhor image copy a ser utilizada, se existir mais de uma disponível.
Use tags com uma estratégia de image copy atualizada no modo incremental para garantir que o backup incremental correto atualize a image copy.

Alternar para image copies, para obter uma rápida recuperação

O uso de image copies pula a etapa de restore e economiza tempo de recuperação.
Use o comando SWITCH TO ... COPY do RMAN para alternar para a image copy mais recente do datafile, tablespace ou database.
O RMAN aplica automaticamente backups incrementais e os archivelogs quando você faz uma recuperação de image copy.
Use as views dinâmicas de desempenho V$TABLESPACE e V$DATAFILE_HEADER para determinar o número do tablespace e datafile que necessita de recuperação.
Após alternar para uma image copy, você pode retornar a uma image copy na localização original quando essa localização estiver disponível.
Use o comando SET NEWNAME no RMAN para identificar novas localizações para os datafiles restaurados.
Depois que você restaurar um ou mais datafiles com o comando RESTORE, use o comando SWITCH para atualizar o controlfile e o recovery catalog com as novas localizações dos datafiles.

Restaurar um banco de dados em um novo host

Restaurar um banco de dados em um novo host é adequado para a recuperação de desastre testando ou movendo permanentemente o banco de dados para um novo host.
O comando DUPLICATE é mais adequado para fazer uma cópia permanente do banco de dados com o novo DBID.
Ao se conectar com o novo banco de dados, não se conecte ao recovery catalog.
O script de recuperação do RMAN usa SET NEWNAME para especificar novas localizações para cada datafile.
Restaure o banco de dados para o SCN do último archivelog.
Você deve abrir o novo banco de dados com RESETLOGS.

Recuperar usando o backup do controlfile

Você pode utilizar um backup automático do RMAN para restaurar um SPFILE ou controlfile quando todas as cópias online desaparecerem.
O RMAN restaura o controlfile em todas as localizações especificadas pelo parâmetro de inicialização CONTROL_FILES.
Se o SPFILE desaparecer, o RMAN usará um SPFILE padrão quando você inicializar o banco de dados no modo NOMOUNT.
Use RESTORE SPFILE FROM AUTOBACKUP para restaurar o SPFILE.
Use RESTORE CONTROLFILE FROM AUTOBACKUP para restaurar o controlfile.
Ao restaurar um controlfile a partir do backup automático, você deve abrir o banco de dados com RESETLOGS.
Opcionalmente, você pode restaurar uma cópia do controlfile em uma localização alternativa.

Fazer uma recuperação de desastre

Uma provável perda de dados ocorrerá se você perder todos os datafiles e controlfile no modo NOARCHIVELOG.
Para fazer uma recuperação de desastre no modo NOARCHIVELOG, use comandos do sistema operacional para copiar os arquivos de backup do banco de dados para a localização original ou alternativa.
Use RECOVER DATABASE UNTIL CANCEL para simular uma recuperação incompleta e reinicializar os arquivos de redo log online.
Após o término da operação de recuperação, abra o banco de dados com RESETLOGS.
Você pode utilizar backups incrementais no modo NOARCHIVELOG para minimizar a perda de dados.
Especifique NOREDO no comando RECOVER DATABASE se todos os arquivos de redo log online desaparecerem.


- Referência Bibliográfica


Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – http://www.bookman.com.br

Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.

Fonte: http://certificacaobd.com.br/2012/04/18/ocp-11g-capitulo-1-resumo-arquitetura-e-asm-parte-1/
Milton Bastos

OCP 11g – Capítulo 4: Criando backups do RMAN

Criar backups de image copies

Os backups do RMAN são backup sets ou image copies.
Os backup sets podem ser criados e lidos somente no RMAN.
A cláusula FORMAT do comando BACKUP especifica as variáveis de substituição para o nome de arquivo do backup de destino.
É possível criar image copies de datafiles, archivelogs e controlfiles.
Image copies só podem ser gravadas em disco.
Use o comando SWITCH para alternar de modo fácil e rápido entre um datafile e a respectiva image copy durante uma operação de recuperação (recovery).

Criar um backup integral do banco de dados

Um backup integral do banco de dados engloba todos os datafiles mais o controlfile.
Um backup completo de um datafile é um subconjunto lógico de um backup integral do banco de dados.
Um backup completo não pode ser utilizado como base para uma estratégia de backup incremental.
Um backup incremental pode ser de nível 0 ou de nível 1.
Um backup incremental de nível 0 pode ser utilizado como base para uma estratégia de backup incremental.
Os backups diferenciais copiam todos os blocos modificados a partir do último backup incremental de nível 0 ou de nível 1.
Os backups incrementais cumulativos incluem todos os blocos modificados a partir do último backup de nível 0.

Ativar o backup incremental rápido

Ative o backup incremental rápido criando um arquivo de rastreamento de mudanças em bloco.
Faça um backup incremental de nível 0 antes de configurar o RMAN para utilizar um arquivo de rastreamento de mudanças em bloco.
A visão do dicionário de dados V$BLOCK_CHANGE_TRACKING informa o nome e o status do arquivo de rastreamento de mudanças em bloco.

Criar um backup duplexado e conjuntos de backup

Os backups duplexados podem reduzir consideravelmente o tempo necessário para criar várias cópias do mesmo backup.
Os backups não podem ser duplexados para a área de recuperação flash, e não é possível duplexar image copies.
Use o comando BACKUP ... BACKUPSET para criar uma cópia de um backup do RMAN em disco ou fita.
O RMAN não incluirá no backup os tablespaces read-only se você utilizar a opção SKIP READONLY no comando BACKUP.
Se você configurar o RMAN para otimização de backup, ele incluirá no backup apenas as cópias adicionais dos tablespaces somente leitura para atender à política de retenção configurada.

Criar um backup de arquivamento para armazenamento prolongado


Um backup de arquivamento é um snapshot do banco de dados em um determinado momento, criado para atender a demandas de arquivamento ou regulatórias.
Os backups de arquivamento facilitam a migração de uma cópia do banco de dados para outro sistema, sem afetar a política de retenção do banco de dados original.
Para criar um backup de arquivamento, especifique a opção KEEP UNTIL TIME ou KEEP FOREVER no comando BACKUP.
O backup de arquivamento do RMAN também inclui os archivelogs necessários para utilizar o backup em uma situação de recuperação.
Você pode usar o comando CHANGE para mudar o status de um backup de arquivamento.

Criar um backup de múltiplas seções, compactado e criptografado

Os backups de múltiplas seções do RMAN podem reduzir bastante o tempo necessário para o backup de datafiles muito grandes em vários destinos.
Você pode executar o comando VALIDATE para backups de múltiplas seções.
O parâmetro SECTION SIZE determina o tamanho de cada seção em um backup de múltiplas seções ou em uma operação de validação.
As views V$BACKUP_SET e RC_BACKUP_SET contêm uma coluna MULTI_SECTION para indicar se o backup é de múltiplas seções.
As views V$BACKUP_DATAFILE e RC_BACKUP_DATAFILE contêm uma coluna SECTION_SIZE com o número de blocos existentes em cada parte de um backup de múltiplas seções.
O RMAN pode compactar os backups dos blocos utilizados através de BZIP2 ou ZLIB.
O ZLIB é mais veloz, mas compacta menos. O BZIP2 é mais lento, mas compacta mais.
A criptografia transparente utiliza uma wallet de banco de dados para criptografar um backup, e este só pode ser restaurado no banco de dados de origem.
A criptografia por senha usa uma senha para criptografar um backup, e este pode ser restaurado no banco de origem e em outro banco de dados.
Você pode utilizar a criptografia transparente e a criptografia por senha no mesmo backup.
A criptografia transparente pode ser ativada para um único backup usando-se o comando SET ENCRYPTION.

Relatórios sobre backups e sua manutenção

O comando LIST fornece informações básicas sobre a disponibilidade dos conjuntos de backup, image copies, cópias de proxy e scripts armazenados.
O comando REPORT apresenta uma visão mais detalhada das informações de backup contidas no catálogo de recuperação.
Você pode utilizar o comando REPORT para identificar os backups obsoletos.
Use o comando REPORT para identificar os datafiles que necessitam de mais cópias de backup para satisfazer a política de retenção.
O comando CROSSCHECK valida as entradas de backup no catálogo de recuperação em relação à existência dos backups em disco ou fita.
O comando DELETE OBSOLETE remove os backups obsoletos do catálogo de recuperação e da localização do backup.
Você pode remover o backups expirados com o comando DELETE EXPIRED.

  - Referência Bibliográfica

Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – http://www.bookman.com.br

Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.

Fonte: http://certificacaobd.com.br/2012/04/18/ocp-11g-capitulo-1-resumo-arquitetura-e-asm-parte-1/
Milton Bastos

OCP 11g – Capítulo 3: Catálogo do RMAN

Identificar situações que exigem o catálogo de recuperação do RMAN (recovery catalog)

     
      ■Se seus backups são simples e o banco de dados não é de missão crítica, provavelmente o controlfile será suficiente para os metadados do RMAN.
      ■Se existirem vários bancos de dados a serem incluídos no backup, e você preferir usar os scripts armazenados, o catálogo de recuperação será altamente recomendável de acordo com as melhores práticas da Oracle.
      ■Ter um repositório central de metadados facilita os relatórios de backup, porque basta utilizar um conjunto de views RC_ em um único banco de dados para consultar as informações de backup.
      ■Somente quando você utiliza um catálogo de recuperação estarão disponíveis alguns comandos úteis do RMAN, como o comando BACKUP ... KEEP FOREVER.

Criar e configurar um catálogo de recuperação

- As três etapas básicas para criar um catálogo de recuperação são:

1.configurar um banco de dados novo ou já existente;
2.criar o proprietário do catálogo de recuperação;
3.criar o próprio catálogo.

      ■Apenas 125MB de espaço em disco são necessários para a implantação inicial do catálogo de recuperação.
      ■A atribuição predefinida RECOVERY_CATALOG_OWNER contém todos os privilégios necessários para gerenciar um catálogo de recuperação, como ALTER SESSION, CREATE SESSION e CREATE TABLE.
      ■Use o comando CREATE CATALOG para criar o catálogo de recuperação.
      ■Você pode utilizar o Enterprise Manager para persistir as credenciais do catálogo de recuperação.

Sincronizar o catálogo de recuperação

      ■A sincronização inicial do catálogo de recuperação utiliza o arquivo de controle do banco de dados de destino.
      ■Cada banco de dados a ser incluído no backup deve ser registrado junto ao catálogo de recuperação através do comando REGISTER DATABASE.
      ■O banco de dados de destino deve estar no estado MOUNT ou OPEN para se registrar com êxito junto ao catálogo de recuperação.
      ■Você pode usar o utilitário DBNEWID (digite nid na linha de comando) para alterar o valor do DBID de um banco de dados. Você pode também alterar o nome do banco de dados como uma opção adicional.
      ■Após modificar o DBID de um banco de dados, você deve reabri-lo com RESETLOGS, e logo em seguida fazer um backup completo do banco de dados.
      ■Você pode cancelar o registro de um banco de dados e um catálogo de recuperação por meio do comando UNREGISTER DATABASE.
      ■Você pode catalogar vários tipos de arquivos de backup no RMAN: cópias de datafiles, backup pieces, cópias de controlfiles e archive logs.
      ■Uma das muitas vantagens do uso de uma área de recuperação flash é o fato de que essa área facilita a recatalogação de todos os arquivos de backup na área, através do comando CATALOG RECOVERY AREA.
      ■A ressincronização manual do catálogo de recuperação é necessária quando esse catálogo não está disponível durante um backup do RMAN. Isso se aplica quando você quiser catalogar archive logs ou implementar alterações físicas no banco de dados de destino.

Criar e utilizar os scripts armazenados do RMAN

      ■Cris scripts armazenados com o comando CREATE SCRIPT ou CREATE GLOBAL SCRIPT.
      ■Scripts locais estão disponíveis somente para o banco de dados de destino.
      ■Scripts globais estão disponíveis para qualquer banco de dados de destino ou até mesmo quando você não estiver conectado com nenhum banco de dados de destino.
      ■Execute um script global ou local dentro de um bloco do comando RUN.
      ■Execute scripts com o comando EXECUTE [GLOBAL] SCRIPT.
      ■O caractere de substituição & permite substituir um valor padrão quando o script for executado.
      ■O comando LIST [GLOBAL] SCRIPT NAMES apresenta uma lista dos scripts globais ou globais e locais existentes no repositório.

■O comando PRINT exibe o conteúdo de um script global ou local.

■Você pode usar REPLACE [GLOBAL] SCRIPT para substituir o conteúdo de um script global ou local.

■DELETE SCRIPT exclui um script do catálogo de recuperação.

Fazer backup do catélogo de recuperação

O banco de dados do catálogo de recuperação é incluído em um backup como qualquer outro banco de dados no ambiente.
O catálogo de recuperação deve estar no modo ARCHIVELOG.
Os utilitários expdp e impdp podem criar backups lógicos do catálogo de recuperação, que podem ser utilizados em uma situação de recuperação de desastre ou para mover o catálogo de recuperação para outro banco de dados.
O uso de tablespaces transportáveis é outra maneira de mover o catálogo de recuperação para outro banco de dados.
Use o comando DROP CATALOG para eliminar um catálogo de recuperação. Não elimine manualmente schemas e packages contidos no banco de dados do catálogo de recuperação.
Execute o comando UPGRADE CATALOG para dar suporte a um cliente do RMAN de uma versão posterior à do banco de dados do catálogo de recuperação.

Criar e utilizar um catálogo privado virtual

Um catálogo privado virtual facilita a divisão das responsabilidades entre vários DBA’s.
Um ou mais catálogos privados virtuais compartilham o mesmo catálogo de recuperação de base.
Conceda a atribuição RECOVERY_CATALOG_OWNER a cada conta de usuário do Oracle que possuirá um catálogo privado virtual.
O proprietário do catálogo de recuperação de base pode conceder permissões sobre bancos de dados registrados existentes aos proprietários de catálogos privados virtuais através do comando GRANT CATALOG.
Assim que você conceder a um user a atribuição RECOVERY_CATALOG_OWNER, o usuário criará um catálogo virtual com o comando CREATE VIRTUAL CATALOG.
O proprietário do catálogo privado virtual usa o comando REGISTER DATABASE para registrar um novo banco de dados, exatamente como um usuário do catálogo de recuperação de base o faria.
Você pode consultar a view do dicionário de dados DBINC para conhecer os bancos de dados acessíveis para o proprietário do catálogo privado virtual.

Configurar as definições de backup

Os backups do RMAN podem ser completos ou incrementais.
Os backups incrementais podem ser de nível 0 ou de nível 1. Os backups de nível 0 são backups completos que você pode utilizar como parte de uma estratégia de backup diferencial, incremental ou incremental cumulativo de nível 1.
As cópias-imagem (image copy) do RMAN são cópias exatas dos datafiles. O uso do RMAN para fazer cópias de datafiles tem a vantagem adicional de verificar a presença de corrupção de dados em cada bloco lido.
O RMAN pode utilizar a compressão de backup para economizar espaço no dispositivo de destino, e ele descompacta automaticamente o backup durante uma operação de recuperação.
O uso de uma área de recuperação flash no RMAN propicia duas vantagens: o RMAN nomeia automaticamente os arquivos de backup na área de recuperação flash e exclui também automaticamente os arquivos obsoletos de backup quando houver pouco espaço na área.
Mais de um banco de dados pode utilizar a mesma área de recuperação flash.
O comando SHOW ALL lista todas as configurações persistentes do RMAN.
Use CONFIGURE CONTROLFILE AUTOBACKUP ON para garantir a existência de uma cópia de backup do controlfile do banco de dados de destino depois de cada operação de backup.
Alocar canais para usar ao fazer um backup
Os canais podem ser persistidos com o comando CONFIGURE ou atribuídos dentro de blocos RUN sando-se o comando ALLOCATE CHANNEL.
Usar DISK como o tipo de dispositivo padrão não exige qualquer alocação de canais.

Configurar a otimização do backup

O RMAN usa a otimização de backup para saltar os backups de um ou mais arquivos se arquivos idênticos foram incluídos no backup em disco ou fita.
A otimização de backup considera as políticas de duplexação e retenção antes de saltar um arquivo de origem.
A otimização de backup é definida no RMAN com o comando CONFIGURE BACKUP OPTIMIZATION ON.


- Referência Bibliográfica


Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – http://www.bookman.com.br

Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.

Fonte: http://certificacaobd.com.br/2012/04/18/ocp-11g-capitulo-1-resumo-arquitetura-e-asm-parte-1/
Milton Bastos

OCP 11g – Capítulo 2: Configurando a Capacidade de Recuperação do Banco de Dados (parte 1)

Configurar a capacidade de recuperação do banco de dados

     
      ■Uma estratégia de backup robusta inclui backups lógicos e físicos.
      ■Um backup lógico de um banco de dados envolve a leitura de um conjunto de linhas do banco de dados e a gravação dessas linhas em um arquivo.
      ■O utilitário Data Pump Export do Oracle consulta o dicionário e grava a saída em um arquivo XML, chamado de arquivo de pump de exportação.
      ■Após a sua exportação por meio do utilitário Data Pump Export, os dados podem ser importados através do utilitário Data Pump Import.
      ■Os backups físicos consistem em copiar os arquivos que formam o banco de dados.
      ■Backups offline consistentes ocorrem quando o banco de dados foi desligado normalmente usando-se a opção NORMAL, IMMEDIATE ou TRANSACTIONAL do comando SHUTDOWN.
      ■Você pode utilizar os backups online em qualquer banco de dados em execução no modo ARCHIVELOG.
      ■No modo ARCHIVELOG, os redo logs online são arquivados, criando um log de todas as transações ocorridas dentro de um banco de dados.
      ■Você pode fazer backups no sistema de arquivos de um banco de dados aberto, desde que esse banco esteja em execução no modo ARCHIVELOG.
      ■É possível recuperar totalmente o banco de dados a partir de um backup online, e esse banco pode ser avançado, através dos archive logs, até o momento anterior à falha.
      ■Os dois tipos básicos de comandos do RMAN são comandos standalone e comandos de job.
      ■A preparação para usar o RMAN em seu ambiente consiste em duas etapas principais: mudar o banco de dados para o modo ARCHIVELOG (se ainda não estiver) e configurar o número e os tipos de destinos de log arquivado para maximizar a capacidade de recuperação e a disponibilidade.
      ■Quando o Oracle for executado no modo ARCHIVELOG, o processo em background ARCn fará uma cópia de cada arquivo de redo log depois que o processo LGWR terminar de gravar no arquivo.

Configurar vários destinos de archive logs para aumentar a disponibilidade

      ■Mudar o banco de dados para o modo ARCHIVELOG aumenta a capacidade de recuperação do banco de dados e permite usar o RMAN como uma ferramenta de backup e recuperação para backups online.
      ■O parâmetro de inicialização DB_RECOVERY_FILE_DEST especifica a localização da Flash Recovery Area (área de recuperação flash), que pode ser em um sistema de arquivos ou em um diskgroup ASM.
      ■Defina pelo menos um parâmetro LOG_ARCHIVE_DEST_n para uma localização fora da Flash Recovery Area.
      ■Defina pelo menos dois parâmetros LOG_ARCHIVE_DEST_n para arquivar em destinos de área de recuperação não flash.
      ■Para um ou dois destinos de arquivo de archive log, você pode utilizar o LOG_ARCHIVE_DEST e LOG_ARCHIVE_DUPLEX_DEST.
      ■Para mais de dois destinos de arquivos de archive log com pelo menos um destino remoto, use LOG_ARCHIVE_DEST_n.
      ■Use o LOG_ARCHIVE_MIN_SUCCEED_DEST para garantir que um número mínimo de destinos de archive logs seja acessado pelo ARCn.

Definir, aplicar e usar a política de retenção

     
      ■O RMAN pode manter e gerenciar backups por meio de uma janela de recuperação ou por redundância.
      ■O uso da política de retenção NONE depende de uma janela de recuperação gerenciada externamente ou da redundância.
      ■A política de retenção do RMAN é 1 cópia.
      ■O parâmetro de inicialização CONTROL_FILE_KEEP_TIME controla por quanto tempo as informações de backup do RMAN serão mantidas no controlfile do banco de dados de destino se o catálogo de recuperação não for utilizado.

Configurar a Flash Recovery Area

      ■A Flash Recovery Area é um local de armazenamento unificado para todos os arquivos relacionados à recuperação em um banco de dados Oracle.
      ■Todos os arquivos necessário para recuperar um banco de dados a partir de uma falha na mídia ou de um erro lógico estão contidos na Flash Recovery Area.
      ■Os itens permanentes mantidos na flash recovery area são: uma cópia do controlfile e cópias espelhadas dos arquivos de redo log online.
      ■Os itens transientes mantidos na flash recovery area são: archivelogs, flashback logs, backups automáticos de controlfile, cópias de datafiles, e arquivos do RMAN usados para preparar uma operação de backup ou de recuperação usando os archivelogs.
      ■O parâmetro de inicialização DB_CREATE_FILE_DEST especifica a localização padrão dos objetos do banco de dados que não informam explicitamente uma localização.
      ■O parâmetro DB_CREATE_ONLINE_LOG_DEST_n especifica um destino padrão para um conjunto de archivelogs.
      ■O parâmetro DB_RECOVERY_FILE_DEST especifica a localização da Flash Recovery Area.
      ■O parâmetro DB_RECOVERY_FILE_DEST_SIZE especifica o tamanho máximo da Flash Recovery Area.
      ■Quando a Flash Recovery Area estiver configurada, o parâmetro de inicialização LOG_ARCHIVE_DEST_10 será automaticamente definido com a localização dessa área.
      ■O tamanho recomendado para a Flash Recovery Area é a soma do tamanho do banco de dados com o tamanho dos backups incrementais e o tamanho de todos os archivelogs não copiados em fita ou em outro local no disco.

Usar a Flash Recovery Area

      ■O parâmetro de inicialização DB_RECOVERY_FILE_DEST_SIZE pode ser aumentado tmeporariamente, assim que for recebdo um alerta, para conceder ao DBA tempo adicional para alocar mais espaço de disco ao diskgroup para realocar a flash recovery area.
      ■A view dinâmica V$RECOVERY_FILE_DEST mostra o total utilizado e o espaço reclamável no sistema de arquivos de destino ou na flash recovery area.
      ■O Oracle gerencia o espaço na flash recovery area e rastreia os arquivos que não são mais necessários para a recuperação ou para funções de flashback.
      ■A view do dicionário de dados DBA_OUTSTANDING_ALERTS contém uma posível ação corretiva para o gerenciamento de espaço na flash recovery area quando a quantidade de espaço disponível nessa área é de 15% ou menos do tamanho total da flash recovery area.


- Referência Bibliográfica


Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – http://www.bookman.com.br

Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.

Fonte: http://certificacaobd.com.br/2012/04/18/ocp-11g-capitulo-1-resumo-arquitetura-e-asm-parte-1/
Milton Bastos

OCP 11g – Capítulo 1: Resumo Arquitetura e ASM

Noções básicas
      
       ■As estruturas lógicas do banco de dados Oracle abrangem tablespaces, segmentos, extensões e blocos, em ordem de granularidade crescente;
       ■Um banco de dados deve possuir, no mínimo, um tablespace SYSTEM e um SYSAUX;
       ■As estruturas físicas do banco de dados Oracle abrangem datafiles, redo log files, controlfiles, archive log files, parameter files, alert/trace files e backup files;
       ■As estruturas de memória do Oracle incluem a SGA (System Global Area), a PGA (Program Global Area) e a Software Code Area;
       ■Os principais processos background do Oracle são: SMON, PMON, DBWn, LGWR, ARCn, CKPT e RECO;
       ■Os processos background que suportam instâncias ASM são RBAL e ARBn; os bancos de dados que utilizam discos ASM tem os processos ASMB e RBAL.
Descrição do ASM
       ■O ASM exige uma instância dedicada para o gerenciamento dos discos compartilhados, chamada de instância ASM;
       ■O rebalanceamento automático de discos em um grupo de discos ASM acontece em segundo plano quando os discos são adicionados ou removidos de um diskgroup ASM;
       ■O processo RBAL em uma instância ASM coordena a atividade dos discos em diskgroups; os processos ARBn executam a movimentação de extensões entre os discos de um diskgroup;
       ■O processo ASMB em uma instância do RDBMS se encarrega da comunicação entre o banco de dados e a instância do ASM; o processo RBAL abre e fecha os discos no diskgroup da instância RDBMS;
       ■Uma instância ASM possui um arquivo de parâmetros de inicialização e um arquivo de senhas, mas como não existem datafiles nessa instância, não há também um dicionário de dados; todas as conexões com uma instância ASM usam autenticação do sistema operacional;
       ■O novo privilégio SYSASM em uma instância do ASM facilita a separação da administração do banco de dados e do armazenamento nessa instância.


Configurar arquivos de parâmetros para instância do ASM e do RDBMS
       ■Para uma instância do ASM, o parâmetro INSTANCE_TYPE é ASM; para uma instância do RDBMS o valor é RDBMS;
       ■O DB_UNIQUE_NAME é +ASM para uma instância do ASM;
       ■O ASM_POWER_LIMIT controla a velocidade das operações de rebalanceamento e varia de 1 a 11;
       ■O ASM_PREFERRED_READ_FAILURE_GROUPS contém uma lista dos grupos de falha preferidos para uma instância do RDBMS quando você utiliza instâncias do ASM em cluster;
       ■Todas as visões dinâmicas de desempenho relacionadas ao ASM estão disponíveis em instâncias do ASM e do RDBMS quando você utiliza instâncias do ASM em cluster;
       ■Um nome de arquivo totalmente qualificado do ASM tem o formato +group/dbname/file type/tag.file.incarnation
       ■Os nomes de arquivo numéricos do ASM são válidos somente para os arquivos existentes do ASM;
       ■Modelos ASM são uma forma rápida de especificar tipos de redundância e striping em um diskgroup ASM;
       ■Os tipos de redundância de um grupo de discos ASM são: externa, normal e alta;
       ■O striping de diskgroups ASM pode ser no modo fine ou coarse.


Inicializar e desligar instâncias do ASM

Uma instância do ASM se encontra no estado MOUNT quando você utiliza o comando STARTUP. Uma instância do ASM não pode estar no estado OPEN, como é possível em uma instância do RDBMS;
Usar STARTUP RESTRICT em uma instância do ASM impede que as instâncias do banco de dados acessem os diskgroups controlados por essa instância do ASM;
Executar uma operação de SHUTDOWN ABORT sobre uma instância do ASM aplica essa mesma operação a todas as instâncias do RDBMS conectadas.
Administrar diskgroups ASM
O striping no modo coarse distribui os arquivos em unidades de 1 MB por todos os discos; o striping no modo fine distribui os arquivos em unidades de 128 KB;
O striping no modo coarse é adequado para ambientes com alto nível de pequenas solicitações de I/O, como em um ambiente OLTP. O striping no modo fine é adequado para um ambiente de data warehouse e maximiza o tempo de resposta para as solicitações individuais de I/O;
Um grupo de falha é um ou mais discos em um diskgroup que compartilham um recurso comum, como uma controladora de disco;
A redundância externa é adequada para os diskgroups não críticos ou para discos gerenciados externamente por uma controladora RAID;
A redundância normal oferece o espelhamento bidirecional e exige dois grupos de falha dentro de um diskgroup;
A redundância alta oferece o espelhamento tridirecional com, no mínimo, três grupos de falha em um grupo de discos;
O espelhamento é gerenciado em um nível muito baixo. As extensões são espelhadas, e não os discos;
Cada disco em cada diskgroup tem uma combinação de extensões primárias e espelhadas;
O rebalanceamento dinâmico ocorre automaticamente em um diskgroup para realocar proporcionalmente os dados de outros membros do diskgroup para o novo membro do grupo;
Geralmente os arquivos ASM são OMF (Oracle Managed Files – Arquivos Gerenciados pelo Oracle), mas podem ser gerenciados manualmente;
O fast mirror resync, disponível a partir do Oracle Database 11g, agiliza o espelhamento do disco por ocasião de uma falha em um disco, como defeito na controladora. Somente os dados modificados precisam ser ressincronizados quando o disco volta ao modo online;
O valor padrão do tempo de reparo de disco é de 3,6 horas, controlado pelo parâmetro de inicialização DISK_RAPAIR_TIME;
É possível monitorar as operações de rebalanceamento de disco na view dinâmica de desempenho V$ASM_OPERATION;
Você pode usar o utilitário de linha de comando ASMCMD para navegar em e manter objetos dentro de grupos de discos ASM;
Os novos comandos ASMCMD do Oracle Database 11g são cp, lsdsk, md_backup, md_restore e remap.

- Referência Bibliográfica
Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – http://www.bookman.com.br
Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.
Fonte: http://certificacaobd.com.br/2012/04/18/ocp-11g-capitulo-1-resumo-arquitetura-e-asm-parte-1/
Milton Bastos

6/28/2012

Oracle GoldenGate

O que é Oracle GoldenGate?


O produto promove a integração rápida de dados em TEMPO REAL e disponibilidade contínua (24×7) dos dados para sistemas de missão crítica. Atualmente, mais de 5.000 clientes utilizam as tecnologias de integração de dados da Oracle.

Sem parar?
Oracle GoldenGate permite replicar dados em tempo real e disponibilidade contínua de aplicativos. A movimentação de dados é feita em tempo real entre sistemas heterogêneos de origem e destino.

Oracle GoldenGate é um produto comprado pela Oracle em 2009, que permite a transferir dados gerados de um banco A para um banco B, ou até mesmo ao contrário tudo que for gerado no banco B ser transferido para o banco A, isso tudo em tempo real.

Aquele seu banco MYSQL, que já cresceu e você deseja migrar para um banco Oracle também é possível. O Oracle GG migra seu banco de dados inteiro, sem parar, sem tempo de janela, tudo online de quase qualquer RDBMS disponível no mercado para Oracle.

A algum tempo venho estudando essa incrível ferramenta e estarei colocando aqui … conceitos, instalações, configurações e muito mais …


Como GoldenGate trabalha?


O GoldenGate é composto pelos seguientes componentes



    •Manager
    •Extract
    •Data pump
    •Replicat
    •Trails files
    •Checkpoints
    •Collector

Manager
Manager é um processo do GoldenGate que desempenha a função de monitorar e restartar (quando necessário) os processos GoldenGate. Erros de eventos ou problemas de lentidão são reportados por ele e também desempenha a função de manter (período) os arquivos de trail e logs do GoldenGate.

Ele deve estar sendo executado em cada configuração GoldenGate antes dos processos Extract e Replicat serem iniciado.

Extract
Esse processo executa em cima do source database e tem a responsabilidade de caputrar os dados e gravar na forma de “trail files” que depois serão enviados para o target database.

Data Pump
Quando o extract escreve para um trail file no source database, o data pump lê esses trail´s e envia atráves de uma rede para o database de destino.

Replicat
Ao contrário do extract, o replicat executa em cima do target database. Ele lê os arquivos trail files enviados pelo Data Pump e então replica essas alterações seja ela DDL ou DML para o database de destino.

Trails files
Todas as mudanças realizadas pelo source database é registrados e armazenadas na forma de arquivos em series assim o GoldenGate é capaz de armazenar essas mudanças temporariamente no disco,

esses arquivos são chamados de trail. Um arquivo trail pode existir tanto no source como no target database.

Checkpoints
Checkpoints assegura que as mudanças feitas pelo database source sejam de certa forma sincronizados com a extração do processo Extract. Ele previne também a redundancia de execuções em ambientes bi-direcionais.

Através dele é permitido usar multiplos Extract e Replicat processos para ler o mesmo arquivo trail.

Collector
Quando o Data Pump envia as informações dos trails através da NetWork, o primeiro processo a lêr essa informação é o Collector, ele recebe as mudanças do database que são enviadas pelo TCP/IP e as escreves para os trails files. O processo manager é quem gerência o momento do Collector capturar os dados.






4/02/2012

RMAN - Recuperando um Banco de Dados Inteiro

====================================================
CONSIDERANDO O SEGUINTE AMBIENTE:
====================================================
- Banco de Dados: Oracle 10g 10.2.0.1 - Enterprise Edition
- Sistema Operacional: Red Hat Advanced Server 4 Update 4
- Modo de arquivamento: Archivelog Ativo.
- Backup: Backup RMAN FULL (Online, Inconsistente, Hot).
- IMPORTANTE: Ter em mãos o DBID=1207426900
- Objetivo: voltar o Backup até o ultimo ponto de recuperação possível.

====================================================
1- PREPARAR UM NOVO SERVIDOR PARA RESTAURAR O BACKUP
====================================================
- Prepara um novo Servidor com Oracle instalado para restauração do Backup RMAN
- Instalar apenas o Software Oracle

====================================================
2- RESTAURAR O SPFILE
====================================================
RMAN TARGET /
RMAN>SET DBID=1207426900
RMAN>startup nomount
RMAN>restore spfile from ‘/oracle10g/backupRMAN/backup_FULL_RMAN_220609/controlfile.ctlc-1207426900-20090622-00′;

Starting restore at 22-JUN-09
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: autobackup found: /oracle10g/backupRMAN/backup_FULL_RMAN_220609/controlfile.ctlc-1207426900-20090622-00
channel ORA_DISK_1: SPFILE restore from autobackup complete
Finished restore at 22-JUN-09
RMAN> shutdown immediate
Oracle instance shut down

====================================================
3- RESTAURAR O CONTROLFILE
====================================================
RMAN>SET DBID=1207426900
RMAN> startup nomount
database is already started
RMAN> restore controlfile from ‘/oracle10g/backupRMAN/backup_FULL_RMAN_220609/controlfile.ctlc-1207426900-20090622-00′;
Starting restore at 22-JUN-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=1091 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output filename=/oracle10g/oradata/BSM/control01.ctl
output filename=/oracle10g/oradata/BSM/control02.ctl
output filename=/oracle10g/oradata/BSM/control03.ctl
Finished restore at 22-JUN-09
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1

====================================================
4- SINCRONIZAR O BACKUP
====================================================
RMAN> CROSSCHECK BACKUP;
RMAN> CROSSCHECK COPY;
RMAN> CROSSCHECK backup of controlfile;
RMAN> CROSSCHECK archivelog all;
RMAN> DELETE EXPIRED BACKUP;
RMAN> delete obsolete device type disk;
RMAN> list backup;


====================================================
5- RESTAURAR O BANCO DE DADOS ORACLE
====================================================
RMAN> restore database;
Starting restore at 22-JUN-09
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00002 to /oracle10g/oradata/BSM/undotbs01.dbf
restoring datafile 00005 to /oracle10g/BSM01.dbf
restoring datafile 00006 to /oracle10g/BSM02.dbf
restoring datafile 00007 to /oracle10g/BSM03.dbf
restoring datafile 00008 to /oracle10g/BSM04.dbf
restoring datafile 00009 to /oracle10g/BSM05.dbf
restoring datafile 00020 to /oracle10g/OBM01.dbf
restoring datafile 00021 to /oracle10g/OBM02.dbf
restoring datafile 00024 to /oracle10g/HINT01.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_                                                                                                          RMAN_220609/backupfullBSM_20090622_qpki6ahi_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qpki6ahi_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:17:35
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00003 to /oracle10g/oradata/BSM/sysaux01.dbf
restoring datafile 00013 to /oracle10g/oradata/BSM/RMAN01.dbf
restoring datafile 00015 to /oracle10g/BSMLOG02.dbf
restoring datafile 00016 to /oracle10g/oradata/MGA01.dbf
restoring datafile 00017 to /oracle10g/oradata/MGA02.dbf
restoring datafile 00018 to /oracle10g/oradata/ELOP01.dbf
restoring datafile 00019 to /oracle10g/oradata/ELOP02.dbf
restoring datafile 00022 to /oracle10g/oradata/_NOVA01.dbf
restoring datafile 00023 to /oracle10g/oradata/_NOVA02..dbf
restoring datafile 00025 to /oracle10g/BSMLOB01.dbf
restoring datafile 00031 to /oracle10g/oradata/BSM301.dbf
restoring datafile 00038 to /oracle10g/oradata/BSM/GERAL01.dbf
restoring datafile 00054 to /oracle10g/oradata/UNTI.dbf
restoring datafile 00060 to /oracle10g/oradata/BSM/BSMREPLIC.dbf
restoring datafile 00061 to /oracle10g/oradata/_CNAB.dbf
restoring datafile 00068 to /oracle10g/IDX.dbf
restoring datafile 00071 to /oracle10g/oradata/FAT01.dbf
restoring datafile 00085 to /oracle10g/oradata/BSM/USR01.dbf
restoring datafile 00086 to /oracle10g/oradata/BSM/USR02.dbf
restoring datafile 00091 to /oracle10g/BSM19.dbf
restoring datafile 00093 to /oracle10g/oradata/BSM/BSMFINANC.dbf
restoring datafile 00095 to /oracle10g/oradata/BSM/INSTERT.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qqki6c7g_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qqki6c7g_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:09:46
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00011 to /oracle10g/oradata/OWERSDF01.dbf
restoring datafile 00026 to /oracle10g/BSM06.dbf
restoring datafile 00027 to /oracle10g/BSM07.dbf
restoring datafile 00028 to /oracle10g/BSM08.dbf
restoring datafile 00029 to /oracle10g/BSM09.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qrki6d2i_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qrki6d2i_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:12:26
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00030 to /oracle10g/BSM10.dbf
restoring datafile 00032 to /oracle10g/HIPTRE02.dbf
restoring datafile 00033 to /oracle10g/ACERT01.dbf
restoring datafile 00062 to /oracle10g/oradata/BSM/WERWER01.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qski6e8h_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qski6e8h_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:04:35
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /oracle10g/oradata/BSM/system01.dbf
restoring datafile 00014 to /oracle10g/BSMLOG01.dbf
restoring datafile 00034 to /oracle10g/ACERT02.dbf
restoring datafile 00035 to /oracle10g/PERT01.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qtki6ek9_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qtki6ek9_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:02:36
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00004 to /oracle10g/oradata/BSM/users01.dbf
restoring datafile 00036 to /oracle10g/PERT02.dbf
restoring datafile 00037 to /oracle10g/BSM_DAD01.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_quki6eqc_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_quki6eqc_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:01:36
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00010 to /oracle10g/oradata/KBSM01.dbf
restoring datafile 00039 to /oracle10g/MWER01.dbf
restoring datafile 00040 to /oracle10g/MWER02.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qvki6etv_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_qvki6etv_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:01:25
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00012 to /oracle10g/oradata/OWER02.dbf
restoring datafile 00075 to /oracle10g/BSM11.dbf
restoring datafile 00076 to /oracle10g/BSM12.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r0ki6f18_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r0ki6f18_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:06:36
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00052 to /oracle10g/oradata/GWER01.dbf
restoring datafile 00081 to /oracle10g/BSM13.dbf
restoring datafile 00082 to /oracle10g/BSM14.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r1ki6fle_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r1ki6fle_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:05:06
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00053 to /oracle10g/oradata/GWER02.dbf
restoring datafile 00087 to /oracle10g/BSM15.dbf
restoring datafile 00088 to /oracle10g/BSM16.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r2ki6g57_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r2ki6g57_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:06:06
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00074 to /oracle10g/oradata/GWER03.dbf
restoring datafile 00089 to /oracle10g/BSM17.dbf
restoring datafile 00090 to /oracle10g/BSM18.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r3ki6go4_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r3ki6go4_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:06:06
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00092 to /oracle10g/BSM20.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r4ki6hb2_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r4ki6hb2_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:02:15
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00107 to /oracle10g/BSM21.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r5ki6hi3_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r5ki6hi3_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00108 to /oracle10g/BSM22.dbf
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r6ki6hjg_1_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/backupfullBSM_20090622_r6ki6hjg_1_1.dbf tag=BKP_FULL
channel ORA_DISK_1: restore complete, elapsed time: 00:00:36
Finished restore at 22-JUN-09

====================================================
6- RECUPERAR O BANCO DE DADOS
====================================================
RMAN> recover database;
Starting recover at 22-JUN-09
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=1088 devtype=DISK
starting media recovery
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=17486
channel ORA_DISK_1: reading from backup piece /oracle10g/backupRMAN/backup_FULL_RMAN_220609/Archivelog_BSM_r8ki6hl4.arc
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle10g/backupRMAN/backup_FULL_RMAN_220609/Archivelog_BSM_r8ki6hl4.arc tag=TAG20090622T040139
channel ORA_DISK_1: restore complete, elapsed time: 00:00:08
archive log filename=/oracle9/1_17486_613563284.arc thread=1 sequence=17486
unable to find archive log
archive log thread=1 sequence=17487
RMAN-00571: =======================================
RMAN-00569: ======= ERROR MESSAGE STACK FOLLOWS ==========
RMAN-00571: =======================================
RMAN-03002: failure of recover command at 06/22/2009 14:07:33
RMAN-06054: media recovery requesting unknown log: thread 1 seq 17487 lowscn 6611212706

====================================================
7- ABRIR O BANCO DE DADOS COM RESETLOGS
====================================================
RMAN> alter database open resetlogs;
database opened
RMAN>



***
Créditos: Bruno Murassaki
http://profissionaloracle.com.br/blogs/brunomurassaki/2009/08/15/rman-recuperando-um-banco-de-dados-inteiro/