Storage Exadata: Protocolo iDB

Salve galera do mal! Eis que estou aqui de volta pra falar mais um assunto da série Storage Exadata. Irei abordar hoje o Intelligent Database Protocol, para os íntimos apenas iDB. Este protocolo é único e somente pode ser encontrado em servidores com storage Exadata e isso não é a toa. O protocolo está implementado no kernel do banco de dados Oracle e foi construído sobre o padrão de indústria RDS (Reliable Datagram Sockets versão 3) e executa sobre a Infiniband ZDP (Zero-Loss Zero-Copy Datagram Protocol) que é uma implementação cópia zero (Zero-Copy) do protocolo RDS, com isso é eliminada a desnecessária cópia de blocos, permitindo maior eficiência na rede.

É graças a este protocolo utilizado em comunicação entre os storage servers e os database nodes que é possível identificar o tipo de I/O que é enviado pelo servidor de banco de dados, por exemplo, seria impossível ter o benefício de cell offloading ou Smart Scan sem este protocolo. Dentro do servidor de storage, estão em execução três principais processos: CELLSRV; Management Server; e Restart Server. Em especial sobre o protocolo iDB, o processo CELLSRV é responsável pelas requisições de I/O efetuadas via iDB para poder efetuar as tratativas inteligentes como o cell offloading.

Foi aqui, no meu ponto de vista, que a Oracle acertou na construção de um hardware que entendesse o que o banco de dados está executando, sem isso nós teríamos apenas servidores ODA (Oracle Database Appliance) no mercado. E é por isso que o Exadata Storage Server é o futuro dos Engineered Systems e será muito difícil novos hardwares tomarem o seu lugar. Pois hardware e inteligência em infraestrutura todo mundo consegue copiar ou aprimorar muito rápido, porém software demora um pouco mais. Galera vou ficando por aqui, aquele abraaaaaaaa.

Overload em Pacotes

Salve, salve, pessoal! Hoje passando por aqui para deixar um post que trata do assunto de Overload em subprogramas nos banco de dados Oracle. Esta técnica é mais conhecida pelos desenvolvedores de PL/SQL e serve para viabilizar a interação do usuário com a chamada de uma função ou procedure dentro de um pacote. Sendo assim, um pacote que encontra-se “sobrecarregado” possui a características de permitir o usuário efetuar a chamada sem necessitar estar amarrado a um tipo de dado.

Alguns pacotes nativos do Oracle possuem essa característica e nós nem nos demos conta. Você já parou para perceber que quando você executa a instrução DBMS_OUTPUT.PUT_LINE(VAR_01) , você nunca liga para o tipo de dado que será colocado na variável VAR_01. Se será um número, uma string ou uma data? Imagine que para um mesmo código, você quer dar a possibilidade ao usuário de efetuar a chamada passando um único parâmetro que pode ser numérico, caracter, LOB ou até mesmo um boolean. É para isso que serve o Overload.

O exemplo que irei exibir é bem simples, portanto, no código abaixo será criado o pacote sobrecarga com os procedimentos execucao que escreverá o valor na tela, referente a cada tipo de chamada. Vejamos abaixo:

pack.sobrecarga

packbody.sobrecarga

sobrecarga.execucao

Percebam que as variáveis declaradas em cada um dos procedimentos são diferentes, assim como os códigos que estão dentro destes. Isso foi feito propositalmente, até mesmo para exemplificar melhor para vocês. Quando forem criar códigos como este, entendam também que existem algumas restrições no uso, entre estas:

  • Subprogramas Standalones não podem ser configuradas, porém você pode utilizar de overload em uma rotina declarada dentro de um bloco PL/SQL anônimo;
  • Subprogramas que diferem somente pelo modo, ou seja, você não pode criar um subprograma com um mesmo tipo porém em um é entrada e no outro saída;
  • Subprogramas com subtipos diferentes, ou seja, um subprograma com overload não pode possuir uma chamada com uma variável do tipo integer e outra real;
  • Subprogramas que diferem somente no tipo de retorno;

Se estas premissas forem cumpridas, você terá configurado com êxito o seu código. Esta técnica pode ser utilizada também em blocos agrupados e métodos de tipo. Bom pessoal, por hoje é só! Aquele abraaaaaaaaaa!

Storage Exadata: Arquitetura

É isso ai rapaziada! Seguindo com mais um post da série sobre Exadata Database Machine, e pegando uma dica do meu amigo David Siqueira, irei abordar a arquitetura do storage desta máquina. Os servidores que possuem os discos que são apresentados para os bancos que estão no Exadata, possuem atualmente (X5-2) dois tipos a serem escolhidos: Alta Capacidade (High Capacity – HC); ou Extreme Flash (EF). Um servidor com discos de alta capacidade possui doze discos SAS de 10K possuindo 4TB cada um, totalizando 48TB de dado raw, se levarmos em consideração que o diskgroup ficará com a redundância normal, o valor cai para algo em torno de 20TB. O ganho na configuração de extreme flash é quando estamos buscando melhor a escrita no banco, pois pelos dados da Oracle, a escrita pode apresentar o dobro da performance se comparado ao disco de alta capacidade, porém a capacidade de armazenamento do EF cai para 25% em relação ao HC.

Os discos físicos presentes nas controladoras de disco de cada cell node são apresentados como luns ao servidor e baseados nestes que podem ser construídos os cell disks para o software do sistema de storage do Exadata. A visão da controladora de disco é que os discos físicos representam o nível mais baixo de abstração de storage, já para a visão do software do Exadata, os cell disks apresentam o maior nível de abstração de storage dos discos físicos, enquanto que as luns apresentam o menor nível. Seguindo no raciocínio, tendo os cell disks montados, um ou mais grid disks podem ser criados a partir deste, para serem apresentados para a instância do ASM onde enfim serão montados ou adicionados aos diskgroups.

zonebit

 

Os grid disks são montados a partir da faixa (offset) mais “quente” do cell disk, por este motivo que em uma configuração padrão os diskgroups são criados seguindo a ordem de: dados; recuperação; e DBFS. A imagem ao lado ilustra um disco físico, onde as faixas cinzas que estão localizadas na área mais longe do centro do disco, são as que apresentam maior velocidade do disco (hot portion), enquanto que as faixas no tom de salmão possuem menor velocidade (cold portion).

 

Somente a Oracle ACS está autorizada a modificar a estrutura dos cell disks após a entrega da máquina (salvo em casos que exista um acompanhamento via SR no suporte da Oracle). Caso a empresa que adquiriu o Exadata Database Machine altere a estrutura, esta poderá perder o suporte do produto pois a autonomia da empresa para modificar a arquitetura dos discos somente compete a nível dos grid disks em diante. Abaixo segue uma imagem detalhando esta arquitetura desde os discos físicos até os grid disks:

Exadata Storage

O que muda no padrão de adição de grid disks de um ambiente convencional é que, deve-se informar os endereços de IPs (Infiniband 01 e 02) do servidor de storage e o nome dos grid disks que serão apresentados para adicionar ou criar estes nos disk groups, já que na configuração máxima de um Exadata poderá ter até 14 nós de células / servidores de storage (não levando em consideração o Expansion Storage Pack que pode chegar a 19 células). Cada grid disk possui o padrão de nomenclatura como <diskgroup_name>_<cell_disk_type>_<cell_disk_number>_<cell_hostname>. Abaixo estão listados os comandos para listar os discos físicos, lunscell disks e grid disks, e também como adicionar os grid disks aos diskgroups.

physical disk

parted lun

lun

griddisk

SYS@SQL> ALTER DISKGROUP <DISKGROUP_NAME> ADD DISK ‘o/<IP_IB01>;<IP_IB02>/<GRIDDISK_NAME>’;
SYS@SQL> ALTER DISKGROUP DATA ADD DISK ‘o/192.168.10.9;192.168.10.10/DATA_CD_00_exa01cell01’;

Como podemos ver acima, os dois grid disks foram montados utilizando um único cell disk e a partir deste grid disk que conseguimos adicionar ou criar os diskgroups no ASM. Bom galera, espero que tenham gostado e até a próxima. Aquele abraaaaaaaaaaa!!!

Storage Exadata: Compressão HCC

Salve, salve, galera do OraCUle! Neste post, abordaremos mais um item da série de posts sobre o Exadata e falaremos sobre a compressão Hybrid Columnar Compression (HCC). Apesar do tema de compressão sugerir ser um tema simples, existem algumas situações que devem ser levadas em consideração sobre o quando e porque da utilização desta feature. Iremos primeiramente abordar o funcionamento da compressão no storage do Exadata.

Diferente do que acontece no storage dos servidores de banco de dados convencionais, nas células do Exadata, os dados são armazenados em uma unidade específica chamada por Compression Unit, para os íntimos, simplesmente, o CU. Brincadeiras a parte, cada unidade de compressão pode variar em tamanho entre 1 e 320 KB, e armazena os dados da tabela de forma colunar, diferente do conceito de armazenamento tradicional que é o armazenamento por registro. Quando ocorre a compressão e quanto maior for esta, maior será o custo de CPU e memória utilizado pelos storage servers.

Outra questão que devemos ter em mente é sobre o comportamento do HCC pois em carga de dados nas tabelas utilizando este tipo de compressão, deve ocorrer Direct Path. Tendo isto em mente, quando ocorrem UPDATES em registros com HCC, o dado comprimido perde esta compressão mas é mantido a compressão FOR OLTP. Sendo assim, é altamente recomendado que os dados que utilizem este tipo de compressão não sejam muito modificados, logo, este tipo de compressão não é recomendado para ambientes OLTP. Sobre os tipos de compressão HCC, existem quatro e abaixo iremos abordar cada um:

  • Compress for Query Low: das taxas de compressão do Exadata, esta é a que permite menor relação de compressão entretanto é a mais direcionada para carga de dados;
  • Compress for Query High: este tipo de compressão é a mais direcionada para leitura e possui uma taxa de compressão melhor que a anterior;
  • Compress for Archive Low: possui uma taxa de compressão melhor que as anteriores e é direcionada a dados históricos com um menor custo de CPU e memória, porém o tempo de carga é elevado;
  • Compress for Archive High: por fim, esta taxa é a que permite melhor taxa de compressão entretanto possui o maior custo de CPU e memória, e por isso é a recomendada para dados históricos;

É importante ter em mente que se o Exadata estiver utilizando este tipo de compressão, melhor será a utilização das demais features que o storage poderá prover (Storage Indexes, Cell Offloading). Efetuei um teste onde foram criadas cinco tabelas idênticas mas uma destas sem compressão e as demais terão as compressões abordadas aqui. Abaixo segue o tamanho final que cada tabela ficou e o seu tempo em segundos de criação, claro que não houve execução com paralelismo já que a intenção era apenas demonstrar o percentual do tempo e tamanho entre as possibilidades de compressão do HCC:

  • Tabela: TEST_NOCOMPRESS .:. Tamanho (GB): 15.53 .:. Tempo de Criação (seg.): 243
  • Tabela: TEST_QUERY_LOW .:. Tamanho (GB): 4.43 .:. Tempo de Criação (seg.): 320
  • Tabela: TEST_QUERY_HIGH .:. Tamanho (GB): 2.50 .:. Tempo de Criação (seg.): 546
  • Tabela: TEST_ARCHIVE_LOW .:. Tamanho (GB): 2.60 .:. Tempo de Criação (seg.): 551
  • Tabela: TEST_ARCHIVE_HIGH .:. Tamanho (GB): 1.70 .:. Tempo de Criação (seg.): 1.843

Com relação a performance das queries em cada tabela, foi executado um simples SELECT COUNT(*) para se obter o tempo de resposta e as estatísticas de cada. Abaixo podemos ver que a nas tabelas que possuem HCC, o Exadata consegue retornar (no pior caso) menos de 4% do tamanho total do segmento para o DB Node – o que representa cerca de 96% de ganho com o Smart Scan – mas na tabela que não possui este tipo de compressão, o ganho com Smart Scan representa cerca de 66%. Com ganho maiores no retorno de dados, isto significa em menor quantidade de I/O para o servidor, gerando melhor utilização de recurso. Para não modificar o nome das estatísticas e melhorar a leitura, os valores de cada uma, eu coloquei os valores em Mega Bytes e expliquei brevemente cada estatística:

  • cell physical IO bytes eligible for predicate offload: Quantidade de bytes processados nos discos físicos onde ocorreu o offloading para as células;
  • cell physical IO interconnect bytes: Quantidade de bytes retornado das células para o servidor de banco;
  • cell physical IO interconnect bytes returned by smart scan: Quantidade de bytes retornado das células para o servidor de banco, apenas com o uso do Smart Scan;

TEST_NOCOMPRESS

  • Tempo de Resposta (seg.): 42,38
  • cell physical IO bytes eligible for predicate offload (MB): 15.443,14
  • cell physical IO interconnect bytes (MB): 5.238,94
  • cell physical IO interconnect bytes returned by smart scan (MB): 5.238,94

TEST_QUERY_LOW

  • Tempo de Resposta (seg.): 40,43
  • cell physical IO bytes eligible for predicate offload (MB): 4.414,84
  • cell physical IO interconnect bytes (MB): 95,57
  • cell physical IO interconnect bytes returned by smart scan (MB): 93,91

TEST_QUERY_HIGH

  • Tempo de Resposta (seg.): 39,41
  • cell physical IO bytes eligible for predicate offload (MB): 2.046,72
  • cell physical IO interconnect bytes (MB): 78,79
  • cell physical IO interconnect bytes returned by smart scan (MB): 75,92

TEST_ARCHIVE_LOW

  • Tempo de Resposta (seg.): 41,36
  • cell physical IO bytes eligible for predicate offload (MB): 2.034,09
  • cell physical IO interconnect bytes (MB): 73,86
  • cell physical IO interconnect bytes returned by smart scan (MB): 71,57

TEST_ARCHIVE_HIGH

  • Tempo de Resposta (seg.): 39,35
  • cell physical IO bytes eligible for predicate offload (MB): 1.688,56
  • cell physical IO interconnect bytes (MB): 62,79
  • cell physical IO interconnect bytes returned by smart scan (MB): 61,62

Bom pessoal, vou ficando por aqui, espero que tenham gostado e logo mais teremos outros posts sobre Exadata. Aquele abraaaaaaaaaaaa.

 

Storage Exadata: Qual o segredo?

Olá, galerinha! Hoje venho postar (bem por alto) sobre algumas das tecnologias do storage Exadata. Em minha humilde opinião, a Oracle acertou em cheio quando lançou no mercado este hardware projetado especificamente para o seu banco de dados. A versão mais recente deste hardware é a X5-2 (adquiridas nas versões de rack: eight; quarter; half; e full) que, diferentemente das versões anteriores, pode-se optar por discos de flash na opção de Extreme Flash. Aliás, nesta versão, o comprador pode também optar por adicionar apenas uma célula e/ou um database node não ficando amarrado nas configurações padrões.

Bom, vou passar brevemente pela arquitetura desta máquina apenas para ilustrar melhor o conceito do software. O hardware é composto por database nodes que hospedam os binários do Oracle Clusterware e as instâncias de banco de dados. E os dados residem nos storage nodes (cell nodes) que possuem os discos e o software. A comunicação entre estes servidores é efetuada através de infinibands switches que apresentam taxas de transmissão de até 40 Gbps. Além disso, temos um swtich de gerencia e as PDUs. Em termos de alta disponibilidade, a máquina apresenta uma solução completa.

Mas afinal, qual o grande lance desta tecnologia já que hardware qualquer fabricante consegue copiar? Em resumo (e na maioria das suas características), eu arrisco dizer que é a inteligência na redução de I/O proporcionado pelo software que está em suas células. E isso só acontece porque há uma comunicação, utilizando o protocolo iDB, entre o banco de dados e as células que informam o tipo de atividade executada. Sendo assim, as células funcionam provendo serviço de dados para o banco de dados nos db nodes.

Vale lembrar que as features abaixo mencionadas estão dentro do conceito de Smart Scan. Esta característica só pode ocorrer se houver (em básico porque existem várias regras) Direct Path no banco de dados, portanto todas as leituras ordenadas em índices (Index Range Scan / Index Unique Scan / Index Max/Min / Index Skip Scan / Index Full Scan), obtém em nada os recursos que somente este storage pode prover. A seguir serão mencionadas algumas destas tecnologias de redução de I/O:

  1. Column Filtering: No Exadata, e como o nome sugere, ocorre o filtro por coluna. Sendo assim, a query que buscar apenas uma coluna da tabela e esta possui dez colunas, somente será retornado os dados desta coluna. Em um servidor convencional, os blocos de toda a tabela seriam retornados do storage para o banco de dados, e este efetuaria o filtro da única coluna mencionada;
  2. Predicate Filtering: Similar a característica anterior, este filtro ocorre a nível de registro. Entenda que quando o banco de dados convencional solicita apenas um registro de uma tabela, e este registro está presente em um único bloco, o bloco por completo será retornado para o servidor de banco de dados, que descartará os demais registros. No Exadata, apenas o registro do bloco é retornado para o banco de dados;
  3. Cell Offloading: Sempre que possível, o trabalho será realizado pelas células. Exemplo, quando uma query pesquisar pela quantidade de funcionários em uma tabela (select count(*) from hr.employees), esta atividade será efetuada pela célula e somente será retornado o valor final para o db node. Em um servidor convencional, todos os dados da tabela seriam retornados para o banco de dados e este teria que efetuar a conta para retornar o resultado. Podem existir casos extremos que, com o grande consumo de atividades nas células, as atividades de offloading podem ser direcionadas para os database nodes executarem;
  4. Storage Indexes: As células tem a inteligência de analisar as pesquisas das queries em determinadas tabelas e viabilizam a construção dos SI (Storage Indexes). Esta estrutura reside na memória das células (sendo assim são perdidas todas as vezes que a célula for desligada) e informa os valores mínimos e máximos da coluna envolvida na query, sendo assim o storage consegue saber exatamente onde está o dado. Esta estrutura consegue montar até oito SIs para uma tabela;
  5. Join Processing: O Exadata utiliza da técnica de Bloom Filtering que é um método probabilístico utilizado quando se envolve uma tabela grande e uma pequena para se testar eficientemente um conjunto de resultados entre ambos. Esta técnica também pode ser analisada em banco de dados que estão acima da versão 11.2.0.4;

Então quer dizer que o storage do Exadata é uma tecnologia direcionada para ambientes com altíssimo volume de dados por transação (DW / DSS), não sendo recomendada para ambientes com alta quantidade transacional de baixo volume de dados (OLTPs com baixa escrita)? Não exatamente. Existem três características do Exadata que consigo avaliar sua utilização benéficas em ambientes OLTPs e estas são:

  1. Exadata Smart Flash Cache: Não confunda esta tecnologia com a Database Smart Flash Cache. A tecnologia que possui no Exadata utiliza os discos flash que constam na célula enquanto que a outra utiliza discos de alta velocidade (SSD). E no Exadata, esta área ainda pode ser configurada como write-back onde o dado será escrito primeiro na cache, liberando a transação e a cache se encarregará de escrevê-lo nos discos das células. Atualmente, pode-se também optar por comprimir os discos flash para aumentar a capacidade da flash cache;
  2. Smart Flash Cache Log: Esta tecnologia, que confunde um pouco as pessoas (inclusive eu estava confuso sobre esta há alguns meses atrás), mantém uma área de dentro de cada uma nas flash cache das células utilizadas exclusivamente para a escrita de redo logs. Sendo assim, quando a célula recebe uma requisição para escrever em seus discos dados de redo, automaticamente esta efetua escrita paralelizada tanto nos discos como na flash cache. Buscando otimizar a escrita do mesmo, pois em ambientes OLTPs, o gargalo pode ocorrer nestas áreas;
  3. Join Processing: mencionado anteriormente e que pode ter uma boa utilização em uniões de tabelas;

Entendo que a tecnologia do Smart Flash Cache com write-back habilitado pode ser um excelente benefício também para ambientes DWs porém quando estamos falando de alto volume de dados neste ambiente, pode ser que as áreas de cache não comportem a capacidade de dados transacionados.

Além destas tecnologias, o Exadata possui a característica de compressão de tabelas chamada HCC (Hybrid Columnar Compression) onde os dados são armazenados e comprimidos a nível de coluna, obtendo ótimos resultados de compressão. Mas por hoje é só e nos próximos posts, irei dar exemplo do funcionamento destas tecnologias de redução de I/O assim como de compressão. Aquele abraaaaaaaa.

Comunidade Oracle em Português

E ae pessoal, tudo bom? Hoje venho apenas postar sobre esta informação de que no mês passado a Oracle passou a abrigar em sua página da comunidade Oracle (community.oracle.com) um espaço voltado para a língua portuguesa. Isso é muito bom porque aproxima mais a comunidade de usuários Oracle do fornecedor. Sem falar que o espaço é moderado pelo Alex Zaballa (Oracle ACE e OCM), time da certificacaobd.com.br e também pelo José Laurindo Chiappa.

Claro que como o espaço é novo, poucas pessoas conhecem e por isso pouco ainda está se falando por lá mas a ideia é justamente esta de fortalecer o espaço com perguntas, dúvidas e sugestões. Para termos mais um acervo de informações sobre o banco de dados Oracle. Segue o link para apreciação: https://community.oracle.com/community/other-languages/portuguese

Bom vou ficando por aqui, forte abraço.

Recuperando Banco de Dados com Data Recovery Advisor

Olá, pessoal. Hoje estou blogando sobre a maneira mais fácil de se recuperar um banco de dados single instance e que poucas pessoas conhecem. Obviamente que este processo deve ser executado através do RMAN (o qual muitos DBAs não conhecem muito bem, infelizmente) mas o trunfo deste procedimento é que nem mesmo quem conhece o conceito de recuperação de um banco consegue executá-lo. Ou até mesmo, pode ser utilizado para estudo pois o procedimento gera e explica o processo de recuperação.

Esta técnica funciona apenas em banco single instance e basta você executar os comandos pelo RMAN após ter conectado no banco, claro. Abaixo estão os comandos e uma breve explicação destes:

  • LIST FAILURE: para listar as falhas encontradas no banco;
  • ADVISE FAILURE: para informar o procedimento a ser executada para recuperar o banco;
  • REPAIR FAILURE: executar o procedimento acima e possivelmente efetuar a recuperação do seu banco. Este passo somente poderá ser executado antes do passo anterior.

Agora vamos a prática, no cenário abaixo irei apagar o datafile da tablespace do SYS com o banco aberto e adivinhem só? Pois é, a base travou. Bom, baixei a base com abort e agora irei tentar iniciá-la, obviamente, a mesma não abre pois não acha o datafile apagado:

SQL> startup     
ORACLE instance started.

Total System Global Area  393375744 bytes
Fixed Size                  1345184 bytes
Variable Size             369101152 bytes
Database Buffers           16777216 bytes
Redo Buffers                6152192 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 – see DBWR trace file
ORA-01110: data file 1:
‘/u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf’

Bom, como eu já havia efetuado um backup antes, irei iniciar a recuperação através dos passos pelo RMAN. Primeiramente, irei listar o erro:

$ rman target /

Recovery Manager: Release 11.2.0.3.0 – Production on Wed Jan 7 23:04:26 2015

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: PROD4 (DBID=1593456204, not open)

RMAN> list failure;

using target database control file instead of recovery catalog
List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
———- ——– ——— ————- ——-
371        CRITICAL OPEN      07-JAN-15     System datafile 1: ‘/u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf’ is missing
334        CRITICAL OPEN      07-JAN-15     System datafile 1: ‘/u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf’ needs media recovery

Atentem para as informações do Summay, esta está indicando que o datafile está faltando e precisará de recuperação. Vamos agora solicitar um “conselho” sobre esta falha:

RMAN> advise failure;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
———- ——– ——— ————- ——-
371        CRITICAL OPEN      07-JAN-15     System datafile 1: ‘/u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf’ is missing
334        CRITICAL OPEN      07-JAN-15     System datafile 1: ‘/u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf’ needs media recovery

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file /u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf was unintentionally renamed or moved, restore it
2. If you restored the wrong version of data file /u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf, then replace it with the correct one

Automated Repair Options
========================
Option Repair Description
—— ——————
1      Restore database and recover with UNTIL CANCEL option  
  Strategy: The repair includes recovery in NOARCHIVELOG mode with some data loss
  Repair script: /u01/app/oracle/diag/rdbms/prod4/PROD4/hm/reco_1763538049.hm

Percebam que até mesmo um script é gerado para efetuar o restore, abaixo está o conteúdo deste:

$ cat /u01/app/oracle/diag/rdbms/prod4/PROD4/hm/reco_1763538049.hm
   # database restore and recover until cancel
   restore database;
   recover database;
   alter database open resetlogs;

Agora vamos seguir o processo e executar a reparação da base através do repair failure, qual irá executar o script acima. Podemos confirmar isso devido as instruções que o RMAN passa:

RMAN> repair failure;

Strategy: The repair includes recovery in NOARCHIVELOG mode with some data loss
Repair script: /u01/app/oracle/diag/rdbms/prod4/PROD4/hm/reco_2809343255.hm

contents of repair script:
   # database restore and recover until cancel
   restore database;
   recover database;
   alter database open resetlogs;

Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script

Starting restore at 07-JAN-15
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/PROD4/datafile/o1_mf_sysaux_9lc3jl1s_.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/PROD4/datafile/o1_mf_undotbs1_9lc3jl2v_.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/PROD4/datafile/o1_mf_users_9lc3jl4g_.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/PROD4/datafile/o1_mf_example_9lc3n46x_.dbf
channel ORA_DISK_1: reading from backup piece /tmp/FULL_PROD4_09ps5gs6
channel ORA_DISK_1: piece handle=/tmp/FULL_PROD4_09ps5gs6 tag=TAG20150107T224734
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 07-JAN-15

Starting recover at 07-JAN-15
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 1 is already on disk as file /u01/app/oracle/oradata/PROD4/onlinelog/o1_mf_1_9lc3mx1r_.log
RMAN-08187: WARNING: media recovery until SCN 1136263 complete
Finished recover at 07-JAN-15

database opened
repair failure complete

Pronto, simples assim e o nosso banco está operacional novamente! Este procedimento é interessante para facilmente recuperar um banco de dados. Claro que o procedimento de recuperação não funciona se o controlfile foi perdido porém qualquer pessoa conseguiria saber o que está acontecendo com o banco de dados. É isso ai galerinha, ficamos por aqui hoje! Forte abraaaaaaaa!!