quarta-feira, 19 de janeiro de 2011

Como adicionar o terceiro nó no Oracle RAC

Voltando de uma longas férias... Que nada eu estava mesmo é envolvido em outros projetos.

O roteiro a seguir descreve de forma bastante simples "Como adicionar o terceiro nó no Oracle RAC". Qualquer dúvida, entre em contato!

----


#1 - Configure o Sistema Operacional do terceiro nó

Instale o sistema operacional com as mesmas opções configurados nos outros nós do cluster

Modifique o arquivo /etc/hosts para incluir este novo servidor por exemplo: rac1, rac1-priv, rac1-vip, rac2, ...

Faça ajustes nas configurações de rede

A partir da versão 9i, a Oracle passou a usar o protocolo UDP no sistema operacional Linux para comunicação IPC (inter-process communication), ou seja, a comunicação entre caches das instâncias dentro do RAC (cache fusion). A Oracle recomenda que se façam ajustes nos parâmetros padrões (default e máximo) do tamanho do buffer de recepção e de envio para 256 KB. Estes buffers são usados pelos protocolos TCP e UDP para armazenar os dados até serem lidos pela aplicação.

Modifique os seguintes parâmetros no arquivo /etc/sysctl.conf :

# Default setting in bytes of the socket receive buffer
net.core.rmem_default=262144

# Default setting in bytes of the socket send buffer
net.core.wmem_default=262144

# Maximum socket receive buffer size which may be set by using
# the SO_RCVBUF socket option
net.core.rmem_max=262144

# Maximum socket send buffer size which may be set by using
# the SO_SNDBUF socket option
net.core.wmem_max=262144

Confirme a alteração executando o comando:

# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144



Crie o usuário oracle e o grupo dba com os mesmos uid e gid dos outros nós configurados no cluster.

# groupadd -g 501 oinstall
# groupadd -g 502 dba
# useradd -m -u 501 -g oinstall -G dba -d /home/oracle -s /bin/bash -c "usuario Oracle" oracle
# id oracle uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba)

Crie CRS_HOME e ORACLE_HOME e conceda os mesmos privilégios dos outros nós.

# mkdir -p /u01/app/oracle
# chown -R oracle:oinstall /u01/app/oracle
# chmod -R 775 /u01/app/oracle

Configure os parâmetros do kernel e hancheck-timer.

Configure os nós do RAC para permitir acesso remoto (ssh ou rsh)

#2 - Adicione o nó ao cluster
execute o script: addNode.sh a partir do diretório: $ORA_CRS_HOME/oui/bin em um dos servidores que participa do RAC.

Clique em NEXT

Especifique o nó que está sendo adicionado. Será apresentada a tela "Cluster Node Addition Progress". Em seguida, deve-se executar os scripts rootaddnode.sh, orainstRoot.sh, root.sh logado com o usuário root.

Siga o processo de execução dos scripts em cada servidor, conforme orientação.

#3 - Instale o software RAC no novo nó da rede

Exceute o script em um dos nós já configurados no RAC:
$ORACLE_HOME/oui/bin/addNode.sh

Clique em NEXT

Na tela "Specify Cluster Nodes to Add to Installation", informe o nó que você prentende instalar e clique em NEXT.

Na tela "Cluster Node Addition Summary", clique next

Será apresentada a tela "Cluster Node Addition Progress" e você será solicitado a executar o script logado com o usuário root:
run root.sh

Será apresentada a tela "End of Installation" para sair da instalação.

Execute no prompt:
$ORACLE_HOME/bin/vipca -nodelist <novo nó> (por exemplo rac3)

A tela de boas vindas VIPCA aparecerá, clique em NEXT

Adicione o IP virtual do novo nó e clique em NEXT.

A tela "Summary" será mostrada, clique em Install.

Aparecerá a tela de progresso da instalação criando e iniciando o recurso de CRS. Após o término, Clique OK, veja os resultados da configuração e clique em EXIT.

Veja se a informação sobre o Interconnect está corret com o comando:

oifcfg getif

Se for preciso mudá-la use o comando:

oifcfg setif <nome da interface>/<ssubrede>:<interconnect|publica>


Exemplo:

oifcfg setif -global eth1/10.10.10.0:cluster_interconnect
ou
oifcfg setif -node <nome do nó> eth1/10.10.10.0:cluster_interconnect

#4 - Reconfigure o LISTENER para o novo nó

Execute NETCA no novo nó

Escolha "Cluster Configuration", clicque em NEXT

Selecione o nó que está instalando o listener, clique em NEXT

Escolha "Listener configuration", clique NEXT.

Selecione "Reconfigure", clique NEXT.

Escolha o listener que deseja reconfigurar, clique NEXT.

Selecione o protocolo, clique NEXT.

Selecione o port, clique NEXT.

Escolha a opção de não configurar outro listener para sair.

Se aparecer a mensagem: "The information provided for this listener is currently in use by another listener...". Clique YES para aceitar.

Aparecerá então a tela "Listener Configuration Complete", clique NEXT.

Clique "Finish" para deixar o aplicativo NETCA

Execute o comando crs_stat para ver se o listener do recurso CRS foi criado.

Examplo: cd $ORA_CRS_HOME/bin ./crs_stat

O novo listener provavelmente estará OFFLINE. Inicie o serviço com o comando:

srvctl start nodeapps -n <novo nó>

Uso comando crs_stat para confirmar se os serviços VIP's, GSD's, ONS's, e listeners estão ONLINE.

#5 - Crie a instância via DBCA

Execute o comando DBCA de um dos nós existentes

Na tela de boas vindas escolha "Oracle Real Application Clusters", clique NEXT.

Selecione "Instance Management", clique NEXT.

Selecione "add an instance", clique NEXT.

Escolha o banco de dados ao qual será adicionada a instância e especifique um usuário com privilégios SYSDBA. clique NEXT duas vezes.

Selecione o nome correto para instância e nó do cluster, clique NEXT.

Confira as configurações de storage, clique NEXT.

Confira a tela com o resumo da instalação e clique OK.

Após término da instalação, quando perguntado se deseja executar outra operação escolha “NO” para sair do aplicativo DBCA

Para conferir se a instalação terminou corretamente, entre em um dos servidores e consulte a view gv$instance, deverão aparecer todos os nós configurados.

Inicie o novo serviço de banco de dados:

$ srvctl start service -s <servico> -d <banco> -i <instancia nova>


Parabéns, Você adicionou mais uma instância ao seu banco de dados RAC!

terça-feira, 23 de novembro de 2010

Como converter uma instância simples (Single Instance) para Oracle RAC?

Neste artigo veremos um passo-a-passo sobre um método manual para converter um instância Simples (single instance) para Oracle database RAC

Informações sobre a instância:

    ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1   
    ORACLE_SID=prod

Localização dos datafiles = /u03/oradata/prod — /u03 está em formato de arquivo OCFS.

Se seus arquivos estão em sistema de arquivo diferente e não compartilhado, você deve compia-los e renomeá-los quando for o caso.

Versão do banco de dados = 10g R2 (10.2.0.1.0)

Passos para conversão dem uma instância simples "single instance" para RAC

Passo 1) Instale o software clusterware em todos os nós que você usará o RAC

Para detalhes de como instalar o software clusterware, veja o link: http://www.viniciusdba.com.br/blog/?p=316 (sempre em português!). As nomenclaturas de diretórios e detalhes de instalação estarão diferentes, informarei sempre as que estou usando.

Basicamente você precisa configurar o endereço IP e outros arquivos do sistema operacional e variáveis de ambiente, antes de instalar o clusterware. Veja o que o blog apresenta uma solução completa.

Importante: A versão do software clusterware deve ser igual a do banco de dados, nunca misture as versões!!

Detalhes da instalação do software clusterware:

    Nome do Cluster : crs
    Diretório de instalação do Cluster : /u01/app/oracle/product/10.2.0/crs
    Diretório do OCR  : /u03/oracrs/ocr.ora
    Diretório do Voting disk : /u03/oracrs/vote.crs

Passo 2) instale o banco de dados Oracle RAC em cluster 10g

Novamente siga as dicas excelentes deste blog: http://www.viniciusdba.com.br/blog/?p=396

Lembrando agora outro fato importante, a versão deste ambiente em RAC deve ser obrigatoriamente a mesma que você estava usando quando tinha uma só instância.

Detalhes da instalação:

    RAC ORACLE_HOME=/u01/app/oracle/product/10.2.0/db
    Número de instâncias = 2
    Nome dos nós para as 2 instãncias = ocvmrh2103, ocvmrh2190

/u01 não está sendo compartilhado entre os nós do cluster.

Passo 3) Faça um backup da sua instância e recupere este backup na partição que está sendo compartilhada (BACKUP/RESTORE).

    Se você estiver usando usando ASM, esta é a forma mais rápida:
        a) Monte os discos usando o caminho do diretório dos datafiles: 
        mkdir /mnt/datafile
        mount /hostdobancooriginal/diretorio/datafile /mnt/datafile -o user=usuario
        >>>informe a senha

        b) Faça o backup (cópia) do seu banco direto para os discos ASM usando o rman
        rman target system/system123@sid
        convert datafile '/mnt/datafile/system01.dbf' format '+disk/datafile/system01.dbf' ;

Passo 4) Faça uma cópia do seu init.ora e adicione os parâmetros para o RAC:

    bash-3.00$ cp initprod.ora /tmp/initprod.ora

    Parâmetros novos no arquivo /tmp/initprod.ora, perceba que as instância agora são numeradas 1 e 2, ok?

    *.cluster_database = TRUE
    *.cluster_database_instances = 2
    *.undo_management=AUTO
    prod1.undo_tablespace=UNDOTBS1
    prod1.instance_name=prod1
    prod1.instance_number=1
    prod1.thread=1
    prod1.local_listener=listener_ocvmrh2103
    prod2.instance_name=prod2
    prod2.instance_number=2
    prod2.local_listener=listener_ocvmrh2190
    prod2.thread=2
    prod2.undo_tablespace=UNDOTBS2

Passo 5) Altere a informação sobre a nova localização do arquivo de controle (controlfile), no arquivo  /tmp/initprod.ora

Passo 6) Cria seu SPFILE
    SQL> create spfile='/u03/oradata/prod/spfileprod.ora' from pfile='/tmp/initprod.ora';

Passo 7) Copie o spfile criado para o diretório : ORACLE_HOME/dbs e crie um novo pfile a partir dele.

    bash-3.00$ cp spfileprod.ora /u01/app/oracle/product/10.2.0/db/dbs/spfileprod.ora
    bash-3.00$ pwd
        /u01/app/oracle/product/10.2.0/db/dbs
    bash-3.00$ cat initprod1.ora
        spfile='/u01/app/oracle/product/10.2.0/db/dbs/spfileprod.ora'

Passo 8) Cria um novo arquivo de senha (password) para a instância prod1 embaixo do Oracle_home do RAC

    bash-3.00$ orapwd file=orapwprod1 password=welcome1

Passo 9) inicialize o banco de dados no modo "MOUNT" e troque os nomes dos datafile e redo log para sua nova localização.

----->>>>Antes confirme se sua varável de ambiente ORACLE_HOME está configurada corretamente:

    bash-3.00$ echo $ORACLE_HOME
    /u01/app/oracle/product/10.2.0/db   
    bash-3.00$ echo $ORACLE_SID
    prod1
   
    SQL> startup mount pfile=initprod1.ora
    ORACLE instance started.

    Total System Global Area  838860800 bytes
    Fixed Size                  1222168 bytes
    Variable Size             213912040 bytes
    Database Buffers          620756992 bytes
    Redo Buffers                2969600 bytes
    Database mounted.

Passo 10) Adicione a sugunda partição do RAC (thread) que irá atender a instância 2

    SQL> alter database add logfile thread 2 group 4 ('/u03/oradata/prod/redo2_01.dbf') size 50M, group 5 ('/u03/oradata/prod/redo2_02.dbf') size 50M, group 6     ('/u03/oradata/prod/redo2_03.dbf') size 50M;
    Database altered.

    SQL> ALTER DATABASE OPEN;
    Database altered.

    SQL> alter database enable public thread 2;
    Database altered.

Passo 11) Crie UNDO tablespace para a instância 2

O nome desta tablespace deve ser o mremos que você especificou no arquivo init.ora no passo 4.

    QL> CREATE UNDO TABLESPACE UNDOTBS2 DATAFILE '/u03/oradata/prod/undotbs2_01.dbf' size 25M;
    ablespace created.

Passo 12) Crie as visões (views) específicas para cluster na instância 1

    QL> @?/rdbms/admin/catclust.sql

Passo 13) No segundo nó do cluster:

Configure o ORACLE_HOME e o SID

    bash-3.00$ export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db
    bash-3.00$ export ORACLE_SID=prod2

Crie o arquivo initprod2.ora igual ao initprod1.ora (da primeira instância). Lembre de copiar também o arquivo spfile para este segundo nó de cluster.

    bash-3.00$ pwd
    /u01/app/oracle/product/10.2.0/db/dbs
    bash-3.00$ ls -lrt spfileprod.ora
    -rw-r-----  1 oracle oinstall 3584 Feb 19 12:36 spfileprod.ora
    bash-3.00$ cat initprod2.ora
    spfile='/u01/app/oracle/product/10.2.0/db/dbs/spfileprod.ora'

Passo 14) Crie um novo arquivo de senhas (password) para esta instância

    bash-3.00$ orapwd file=orapwprod2 password=welcome1

Passo 15) Crie os diretórios (mkdir) para os arquivos, conforme informado no init.ora,  abaixo:
    audit_file_dest
    background_dump_dest
    user_dump_dest
    core_dump_dest


Passo 16) Inicialize a segunda instância

    SQL> startup pfile=initprod2.ora
    ORACLE instance started.

    Total System Global Area  838860800 bytes
    Fixed Size                  1222168 bytes
    Variable Size             213912040 bytes
    Database Buffers          620756992 bytes
    Redo Buffers                2969600 bytes
    Database mounted.
    Database opened.


Passo 17) Agora é só adicionar os serviços do cluster

    bash-3.00$ srvctl add database -d prod -o /u01/app/oracle/product/10.2.0/db -p /u03/oradata/prod/spfileprod.ora
    bash-3.00$ srvctl add instance -d prod -i prod1 -n OCVMRH2103
    bash-3.00$ srvctl add instance -d prod -i prod2 -n OCVMRH2190


Referência:
Metalink Note ID : 747457.1


Fique à vontade para tirar dúvidas comigo. Espero que você tenha Sucesso!


Luis Adelson.

sábado, 13 de novembro de 2010

ORA-600 erro genérico

Já tive problemas com ORA-600 que demorou dias para o suporte Oracle resolver, aliás ainda tenho um chamado aberto no Metalink aguardando solução.

O que a Oracle fez? Mandou que nós alterássemos o modo de conexão do banco de shared para dedicated. Ou seja, não podemos mais usar pool de conexões. Parece engraçado, mas não é tanto assim. Pois deram uma solução paliativa, ou solução quebra-galho, fazer o quê?


No entanto, encontrei este artigo muito bom do Rodrigo Almeida e gostaria de compartilhar aqui. Aproveitem que esse cara manja do assunto.

http://www.rodrigoalmeida.net/blog/achei-um-ora-600-o-que-faco

Parabéns mais uma vez Rodrigo!


Adelson Luniere.

quarta-feira, 20 de outubro de 2010

Qual é a diferença entre Database, Instance e Service Name?

Se você um dia for trabalhar com RAC, leia este artigo!


Database Name. É o nome usado para a estrutura física do banco de dados. Esta informação é armazenada no cabeçalho do control file e datafile. Usado para identificar todas as estruturas físicas que pertencem ao mesmo banco de dados. Definido no momento da instalação. Originalmente defnido pelo parâmetro estático denominado database_name e não pode ser mudado, a não ser que você recrie seu controlfile e reset a sequência de logs.

Instance Name.É o nome dado às estruturas de memória + processos de Background (MEM + BGP) usado para montar e abrir o banco de dados. No ambiente RAC existem mais de uma instância abrindo o mesmo banco de dados e cada instância deve ter nomes diferentes. Num ambiente sem RAC, geralmente o nome da instância e o nome do banco de dados são iguais. Não é preciso usar nomes diferentes.O nome da instância é definido pela variável de ambiente chamada ORACLE_SID. Usada para estabelecer a conexão com o banco de dados como uma "connect string".

Service Name. É definido pelo parâmetro dinâmico denominado service_names, no plural, porque podem ser definidos diversos nomes de serviços, dependendo da necessidade de configuração. Exemplo de uso: fail over (contingência), resource manager (controle de recursos), balanceamento de recursos.

Vamos nos aprofundar mais um pouco em serviço ou Service Name?

Um serviço é uma representação lógica de uma ou mais instância. Quando você especifica SERVICE_NAMES="AlgumaCoisa" no seu arquivo tnsnames.ora você não está pedindo para se conectar a uma instância especifica. De fato o que você está dizendo é que "não me interessa a qual instância estou sendo conectado, contanto que eu receba o serviço esperado".

Num ambiente onde existe somente uma instância, service_names e instance são sinônimos, ou seja, uma coleção de estruturas de memória e processos que fornecem um serviço. Portanto, não faz sentido alocar mais de um service_names para uma mesma instância.

O conceito de serviço faz muito mais sentido num ambiente onde existem várias instâncias (RAC - Real Application Cluster). Nesse ambiente algumas instâncias podem fornecer um serviço, enquanto outras podem oferecer outros serviços. Um serviço então pode ser uma forma de fazer um particionamento lógico do seu ambiente em RAC em áreas funcionais. Nesse caso, o serviço seria utilizado para dividir e priorizar recursos dentro de um RAC.

O serviço é a chave para um ambiente em contingência uma vez que ele não significa "conecte-me a uma instância". Por exemplo, se você disse conecte-me ao SID=INST1, então você solicitou uma conexão a uma determinada instância, mas se esta instância cair, tudo bem, você perdeu a conexão ao banco de dados, mas foi uma opção feita por você. Você pediu, você recebeu! Se ao invés disso você se conectar ao serviço VENDAS que está sendo fornecido pelas instâncias INST1 e INST2, então se a instância INST1 cair por qualquer motivo, o mesmo serviço estará sendo fornecido pela INST2 e você será conectado a segunda instância como forma de contingência.

Este conceito explica porque nunca deverá existir um banco de dados chamado VENDAS e as instâncias e serviços serem também nomeados como VENDAS. Também não deverão existir instâncias chamadas VENDAS1 e VENDAS2 e serviços chamados VENDAS1 e VENDAS2. Este equívoco contraria o conceito de service_names. O correto então seria ter um serviço chamado VENDAS, as instância denominadas VENDAS1 e VENDAS2 e o banco de dados seria VENDASDB. Nenhum conflito de nomes e conceitos, ok?

É crítico dominar estes conceitos principalmente quando se migra para um ambiente no qual se usa RAC ou Data Guard. Esta sútil diferença ajuda principalmente quando vemos que muitos costumam confundir serviço com instância e depois sofrem quando migram para o RAC porque recebem erros na configuração do ambiente.

Esse não será você!

terça-feira, 19 de outubro de 2010

ORA-00313 ,ORA-00312 - Erro na abertura de redo logs

Sempre que você migrar seu banco de dados, tenha em mente que a opção archive log deve ser desativada, caso contrário você poderá receber estes erros ORA.

ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/oradata2/data1/dbase/redo02.log'

Ah, você esqueceu? Não tem problema, vamos ver como abrir seu banco mesmo assim.

Causa do problema:
-----------------------------
Seu banco de dados estava em modo archive, Você deu shutdown e quando tenta o startup, seu redo log pode não mexistir ou está corrompido (open reset logs)

Solução do problema:
--------------------------------
A)Monte the database.
SQL>STARTUP MOUNT
Database mounted.

B) Verifique a condição do logile para certificar que ele é o corrente.

SQL> SELECT STATUS FROM V$LOG WHERE GROUP#=2;
STATUS
----------------
CURRENT

C) Se ele não for o corrente (CURRENT) ent~/ao simplesmente remova (drop) o log file by,
SQL>ALTER DATABASE DROP LOGFILE GROUP 2;

Se existirem somente 2 grupos de log, então será necessário incluir um novo grupo, antes de remover um deles, pois devem existir no mínimo 2 log groups.

Então antes da remoção:

SQL>ALTER DATABASE ADD LOGFILE GROUP 4 '/oradata2/redo3.log' SIZE 10M;

Como a condição de CURRENT não permite remover o grupo, você deverá executar uma recuperação FALSA antes de abrir com a opção "resetlogs".

SQL>RECOVER DATABASE UNTIL CANCEL;
Responda com CANCEL.

Agora você já pode abrir seu banco de dados!
SQL>ALTER DATABASE OPEN RESETLOGS;

quinta-feira, 14 de outubro de 2010

EXALOGIC - Solução Oracle para aplicações Web

Executar todas as suas aplicações num servidor único? Essa seria a nova estratégia da Oracle conhecida como "Cloud in a box" - algo como nuvem de processamento numa caixa (servidor). Denominado de Exalogic computação em nuvem, esta solução provê a possibilidade de uma configuração mais simples até a expansão de vários hardwares conectados entre sí.

Este hardware elegante que exibe os logos da SUN e ORACLE pode ser configurado com 30 servidores composto de 360 núcleos, rede (InfiniBand de 40Gbits) e armazenamento (storage SUN). Faz parte do pacote de soluções a tecnologia de virtualização da Oracle (VM) com a possibilidade de escolha entre os sistemas operacionais Solaris e Linux. De fato, o pacote completo Exalogic inclui ainda O software Exalogic, sistema operacional, o Oracle JRockit e HotSpot, e WebLogic e Oracle Coherence caching solution.

O conceito de nuvem da Oracle seria uma plataforma de aplicativos baseados em padrões e plataforma de execução. Isto inclui hardware e software. É virtual e expansível e executa uma variedade de aplicações.

A proposta do Exalogic é atender à aplicações em ambientes AWS, ou seja, voltados à WEB. Os testes de benchmark mostraram uma melhora de 12 vezes na performance das aplicações desenvolvidas para a internet.

Feito para suportar requisições de HTTP superiores a 1 milhão por segundo, seria como se fosse possível suportar o tráfico do Facebook em apenas 2 racks. Além disso, O Exalogic mostrou excelente performance no tratamento de mensagens, na ordem de 1,8 milhões de mensagens por segundo.

De fato, o sistema Exalogic seria mais apropriado para entregar a melhor performance em aplicações Java, com possibilidade de expansão, tolerância à falha, segurança e simplicidade de manutenção.

Outro comparativo, segundo a Oracle, demonstraria que o sistema Exalogic teria um custo 4 vezes inferior ao dos melhores servidores IBM, além da possibilidade de crescimento em até 8 racks. A linha top da IBM, o Power 795 system, não teria essa escalabilidade.

A Orale lançou também uma nova versão do Unbreakable Enterprise Kernel, sistema operacional Linux da Oracle. A promessa é entregar um sistema operacional 5 vezes mais performático que o Linux Rad Hat.

"O Red Hat se encontra 4 anos atrasado tecnologicamente, isto é um problema enorme para nós", informou Ellison (CEO da Oracle). "Não podemos nos dar ao luxo de ficar atrasados em 4 anos" completou Ellison.

A solução Exalogic parece vir complementar o sistema Exadata (recomendado para DatawareHouse), criando um parceria de sucesso em performance. No entanto, ainda não parece ser viável para aplicações transacionais, seja por seu custo ou mesmo pela sua natureza que seria atender grandes bases de dados suportando ambientes Java na Web.

Mas novidades na Oracle não param por aí. Ainda em 2010 deverá ser lançado uma máquina voltada para aplicações OLTP (transacionais).

quarta-feira, 6 de outubro de 2010

Abrir Banco de dados sem REDOs e ARCHIVEs, É possível?

Se você não possui salva do seu banco de dados e archivelogs tudo pode estar perdido...

A não ser que você conheça o parâmetro _ALLOW_RESETLOGS_CORRUPTION = TRUE.
Sua única chance de recuperar seu banco. Este parâmetro não é suportado pela Oracle. Então use com moderação.
Inclua este parâmetro no seu pfile e então abra o banco de dados com a opção OPEN RESETLOGS. Depois remova-o e execute os seguintes passos:

1) Faça export full de toda a base de dados.
2) Crie um control file "alter database backup controlfile to trace;".
3) Edite o arquivo de trace (*.trc ), localizado no diretório user_dump_dest, para remover todos os datafiles exceto o SYSTEM, TEMP and RBS/UNDO. Então renomeie o arquivo .trc para .sql com um nome sugestivo.
4) Salve o arquivo INIT<SID>.ORA que será usado mais tarde.
5) Recrie o banco de dados conectando-se com a instância IDLE e execute STARTUP NOMOUNT (use o pfile do passo 4) use o comando CREATE CONTROLFILE ... LOGFILE ... DATAFILE ... a partir do arquivo criado no passo 3.
6) Execute o CATALOG, CATPROC como se estivesse criando um banco de dados novo.
7) Faça um import do arquivo de dump criado no passo 1. Este procedimento criará todos os indexes e dados nas tabelas.
8) As transações perdidas poderão agora ser recriadas a partir de programas que abortaram o momento da perda do banco de dados.

Pronto! Eu já precisei disso, mas o melhor sempre é fazer backup.
"Só Jesus SALVA, o homem faz BACKUP".