Blog do Rodrigo Almeida

Olá,

Uma dos maiores problemas de realizar uma recuperação completa ou uma restauração de um banco de dados para um novo servidor, é o problema de mencionar o DBID (Database Identifier - Identificação do banco de dados) para o catálogo do RMAN.

Pois, para conseguir uma restauração da base, é necessário mencionar o DBID ao catálogo de recuperação para conseguir associar o banco de dados no catálogo e posteriormente restaurar e recuperar seus backups sets.

Agora, vamos mencionar quais os meios que podemos encontrar o DBID de um banco de dados.

1. Dicionário de dados

Podemos realizar um simples select na view v$database para conseguir a informação, veja.

SQL> select dbid from v$database;

      DBID
----------
4263396950

1 linha selecionada.

2. RMAN - Inicío de sessão

O DBID também é informado quando você conecta ao RMAN, lembrando, que o DBID será informado se o banco de dados estiver em MOUNT ou OPEN, se apenas com NOMOUNT, não será informado, pois não irá ler o arquivo de controle, ou control file. Exemplo.

[oracle@PELSPOWMS2 ~]$ rman

Recovery Manager: Release 10.2.0.1.0 - Production on Thu Oct 23 17:15:23 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

RMAN> connect target ‘rman/##########@wmssp.world’;

connected to target database: WMSSP (DBID=4263396950)

RMAN>

3. RMAN - Usando o comando List incarnation

Outro modo de se conseguir o DBID do banco de dados, é após logar-se no banco de dados target e estar conectado ao catálogo de recuperação, utilizar o comando LIST INCARNATION, exemplo:

RMAN> list incarnation;
List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
8451    8458    WMSSP    4263396950       PARENT  1          30/06/2005 19:09:40
8451    8452    WMSSP    4263396950       CURRENT 446075     27/02/2008 09:03:20

RMAN>

Uma dica muito importante é sempre manter uma planilha com todos os bancos de dados, senhas e seus respectivos DBID armazenados após as criação do banco de dados para não correr risco de não saber o DBID do banco de dados criado.

Abraços,

Olá,

Nesse post vamos realizar um simples backup e recover do controlfile do banco de dados utilizando o RMAN, sem a necessidade de um catálogo de recuperação.

Nos exemplos, vou utilizar a versão XE (Oracle Express Edition) que é gratuita e disponível para download no site da Oracle Technology Network e também fornacerá um pequeno treinamento na utilização do RMAN. Pois bem, vamos checar alguns pontos para iniciar nossos testes, como demostrado abaixo:

C:\>start OracleServiceXE
O sistema não pode encontrar o arquivo OracleServiceXE.

C:\>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:28:33 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> @id

HORA EXECUTADA
-------------------
22-08-2008 13:28:36
INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              DBARODRIGO          OPEN

USER IS "SYS"

SQL> select * from v$controlfile;
STATUS     NAME                                                         IS_ BLOCK_SIZE FILE_SIZE_BLKS
---------- ------------------------------------------------------------ --- ---------- --------------
           C:\ORACLE\ORADATA\XE\CONTROL.DBF                             NO       16384            430

Atenção

Existe uma etapa que emito o comando @id, ele é apenas um script que utilizo para ver as horas, instância, servidor e o status da instância. Ele está disponível na área de script aqui do Blog, depois comento como configurar o SQLPATH para executar scripts sem a necessidade do caminho absoluto. Não confunda com um comando interno do banco de dados ou do SQL*PLUS.

Nessas etapas, estamos apenas checando informações básicas do banco e onde está seu controlfile, por padrão no XE, o controlfile veem com extensão DBF, o que pode ser um pouco diferente para quem geralmente trabalha com os controlfiles em extensão CTL (mas, não muda nada!).

Agora, vamos executar um backup atual do nosso controlfile com o RMAN, para termos um backup atualizado em casos de futuros problemas. O processo a seguir irá desativar o banco de dados pelo SQL*PLUS e posteriormente, logar-se pelo RMAN e iniciar o banco de dados no estado montado, ou seja, vou apenas abrir o controlfile do banco de dados e coletar as suas informações, porém, nesse estado, fica inutilizável para os usuários.

SQL> shutdown immediate;
Banco de dados fechado.
Banco de dados desmontado.
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

C:\>rman target /

Gerenciador de Recuperação: Release 10.2.0.1.0 - Production on Sex Ago 22 13:30:48 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

conectado ao banco de dados de destino (não iniciado)

RMAN> startup mount;

instância Oracle iniciada
banco de dados montado

Total da área Global do Sistema     146800640 bytes

Fixed Size                     1286220 bytes
Variable Size                 62918580 bytes
Database Buffers              79691776 bytes
Redo Buffers                   2904064 bytes

RMAN> list backup of controlfile;

usar o arquivo de controle do banco de dados de destino em vez do catálogo de recuperação

Lista de Conjuntos de Backup
===================

RMAN>

Observe, executei o comando shutdown immediate para desativar o banco de dados, e logo em seguida, me conectei no RMAN usando uma autenticação pelo sistema operacional, por isso o (target /), e sem a necessidade de um catálogo de recuperação, pois o RMAN quando não usa um catálogo de recuperação pega as informações do controlfile, sobre SCN, datafiles, logs e etc.

Para uma simples conferência, acima executei o comando LIST BACKUP OF CONTROLFILE apenas para saber se já exisitia ou não um backup do controlfile. E Finalmente o mais interessante, como realizar o backup do controlfile:

RMAN> run {
2> allocate channel t1 type disk format 'c:\oracle\backup\rman\BKP_CF_%d_%t_%s.rman';
3> backup current controlfile tag 'BKP_CF';
4> release channel t1;
5> }

canal alocado: t1
canal t1: sid=35 devtype=DISK

Iniciando backup em 22/08/08
canal t1: iniciando conjunto de backup completo de arquivo de dados
canal t1: especificando arquivo(s) de dados no conjunto de backups
incluindo arquivo de controle atual no conjunto de backups
canal t1: iniciando o componente 1 em 22/08/08
canal t1: componente 1 finalizado em 22/08/08
handle de componente=C:\ORACLE\BACKUP\RMAN\BKP_CF_XE_663427972_18.RMAN tag=BKP_CF comentário=NONE
canal t1: conjunto de backups concluído, tempo decorrido: 00:00:05
Finalizado backup em 22/08/08

canal liberado: t1

RMAN> exit

No script acima, coloquei apenas um canal de I/O para realizar o backup e mandar para o destino do backup, que no exemplo, foi “c:\oracle\backup\rman\”, sempre utilizo variáveis de ambiente do RMAN para gerar o meu arquivo de backupset, no caso, %d (nome do banco de dados), %t (timestamp) e %s (sequência de backupsets gerados) junto com a extensão .RMAN, para saber que foi gerado pelo Recovery Manager.

Após realizar a tarefa, vamos ver o arquivo gerado e posteriormente os passos para simular a restauração do controlfile, todos os passos estão abaixo:

C:\>cd c:\oracle\backup\rman

C:\oracle\backup\rman>dir
 O volume na unidade C é DBA
 O número de série do volume é 7A9D-6C81

 Pasta de C:\oracle\backup\rman

22/08/2008  13:32    <DIR>          .
22/08/2008  13:32    <DIR>          ..
19/08/2008  21:58               187 afiedt.buf
22/08/2008  13:32         7.110.656 BKP_CF_XE_663427972_18.RMAN
              2 arquivo(s)  7.110.853 bytes
               2 pasta(s)  5.920.763.904 bytes disponíveis

Agora, vou para a pasta que está os arquivos de dados do Oracle XE, para deletar o controlfile.

C:\oracle\backup\rman>cd ..

C:\oracle\backup>cd ..

C:\oracle>cd oradata

C:\oracle\oradata>cd xe

C:\oracle\oradata\XE>dir
 O volume na unidade C é DBA
 O número de série do volume é 7A9D-6C81

 Pasta de C:\oracle\oradata\XE

19/08/2008  22:21    <DIR>          .
19/08/2008  22:21    <DIR>          ..
22/08/2008  13:33         7.061.504 CONTROL.DBF
22/08/2008  13:30       450.895.872 SYSAUX.DBF
22/08/2008  13:30       356.524.032 SYSTEM.DBF
19/08/2008  22:21        20.979.712 TEMP.DBF
22/08/2008  13:30        94.380.032 UNDO.DBF
22/08/2008  13:30       104.865.792 USERS.DBF
               6 arquivo(s)  1.034.706.944 bytes
               2 pasta(s)  5.920.763.904 bytes disponíveis

Vou logar no banco de dados novamente, para deletar o arquivo, pois, em ambiente windows, não é possível deletar os arquivos quando estão em uso. Então segue novamente os passos. Lembrando que meu banco de dados sempre esteve no modo MOUNT.

C:\oracle\oradata\XE>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:34:51 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> shutdown immediate;
ORA-01109: banco de dados não aberto
Banco de dados desmontado.
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

C:\oracle\oradata\XE>del /F /Q CONTROL.DBF

C:\oracle\oradata\XE>dir
 O volume na unidade C é DBA
 O número de série do volume é 7A9D-6C81

 Pasta de C:\oracle\oradata\XE

22/08/2008  13:35    <DIR>          .
22/08/2008  13:35    <DIR>          ..
22/08/2008  13:30       450.895.872 SYSAUX.DBF
22/08/2008  13:30       356.524.032 SYSTEM.DBF
19/08/2008  22:21        20.979.712 TEMP.DBF
22/08/2008  13:30        94.380.032 UNDO.DBF
22/08/2008  13:30       104.865.792 USERS.DBF
               5 arquivo(s)  1.027.645.440 bytes
               2 pasta(s)  5.927.821.312 bytes disponíveis

C:\oracle\oradata\XE>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:35:25 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a uma instância inativa.

SQL> startup;
Instância ORACLE iniciada.

Total System Global Area  146800640 bytes
Fixed Size                  1286220 bytes
Variable Size              62918580 bytes
Database Buffers           79691776 bytes
Redo Buffers                2904064 bytes
ORA-00205: erro na identificação do arquivo de controle, verifique o log de alertas para obter mais informações
SQL> @id

HORA EXECUTADA
-------------------
22-08-2008 13:35:36
INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              PELSPOMARIO          STARTED

USER IS "SYS"
SQL> shutdown immediate;
ORA-01507: banco de dados n?o montado
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

Depois de todo o processo, e ao deletar o CONTROL.DBF, tentei iniciar o banco de dados e apareceu a seguinte mensagem de erro, ORA-00205, onde não foi possível encontrar um controlfile para montar o banco de dados e posteriormente abrir aos usuários.

Isso é comum quando se perde um controlfile, em ambiente corporativos o controlfile sempre estará multiplexado, ou seja, sempre terá uma cópia fiel dos controlfile na abertura do banco, porém, dependentdo do crash, o Oracle pode dizer que um controlfile está mais atualizado que o outro, e isso é um assunto para outro post. rs.

Mas, vamos em frente, o que temos que fazer agora é apenas restaurar o controlfile que fizemos backup no início do post, aquele que foi gerado no caminho “c:\oracle\backup\rman”, e o processo de restauração também é bem fácil, observe a recuperação abaixo:

C:\oracle\oradata\XE>rman target /

Gerenciador de Recuperação: Release 10.2.0.1.0 - Production on Sex Ago 22 13:36:05 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

conectado ao banco de dados de destino (não iniciado)

RMAN> startup nomount;

instância Oracle iniciada

Total da área Global do Sistema     146800640 bytes

Fixed Size                     1286220 bytes
Variable Size                 62918580 bytes
Database Buffers              79691776 bytes
Redo Buffers                   2904064 bytes

RMAN> restore controlfile from 'c:\oracle\backup\rman\BKP_CF_XE_663427972_18.RMAN';

Iniciando restore em 22/08/08
usar o arquivo de controle do banco de dados de destino em vez do catálogo de recuperação
canal alocado: ORA_DISK_1
canal ORA_DISK_1: sid=36 devtype=DISK

canal ORA_DISK_1: restaurando arquivo de controle
canal ORA_DISK_1: restauração concluída, tempo decorrido: 00:00:03
nome do arquivo de saída=C:\ORACLE\ORADATA\XE\CONTROL.DBF
Finalizado restore em 22/08/08

RMAN> alter database mount;

banco de dados montado
canal liberado: ORA_DISK_1

RMAN> alter database open resetlogs;

banco de dados aberto.

C:\oracle\oradata\XE>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:38:15 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> @id

HORA EXECUTADA
-------------------
22-08-2008 13:39:41
INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              PELSPOMARIO          OPEN

 

 PRONTO! Olhe no início do LOG que ao se conectar ao RMAN, peço para realizar a restauração do controlfile pelo arquivo gerado pelo backup, ou seja, do arquivo ‘c:\oracle\backup\rman\BKP_CF_XE_663427972_18.RMAN’, e assim sendo após a restauração com sucesso é só mandar abrir o banco de dados com a opção RESETLOGS (será gerado uma nova incarnação) e permitir o acesso novamente dos usuários.

A ideia do post, vou comentar de maneira bem rápida e de fácil entendimento, como podemos realizar um backup e restore do controlfile de um banco de dados. Espero que tenham gostado.

Abraços,

 

 

Olá,

O título desse post já diz muita coisa, “Achei um ORA-600, o que faço?”. Muitos gostariam de ter o botão EJECT na cadeira, outros de ser ninjas e jogar o pó para desaparecer e alguns gostariam de ser o novo David Blaine. Na verdade, esse número “cabalístico” de erro pode ser o início de uma longa jornada.

O RDBMS (Relational Database Management System) Oracle possui dois códigos de erros que assustam qualquer DBA, o bendito ORA-600 e ORA-7445, mas nesse momento, vamos refletir sobre o ORA-600, o que ele realmente significa para nós.

Quando nós encontramos ele no alert.log ou diretamente pelo Oracle Server (via SQL*PLUS ou qualquer outra aplicação), significa que temos um problema na aceitação do comando no kernel do RDBMS ou temos uma inconsistência em um determinado processo, que geralmente, pode estar associado a um BUG, **MAS**, nem sempre é um BUG, por isso que temos que ter muita calma nessa hora. O Metalink disponibiliza uma ferramenta de pesquisa para esse específico erro, o chamado ORA-600 Lookup tool. Atráves dele, pode ser encontrado a solução para seu específico erro, se existe um patchoff para correção ou se existe um simples workarround “gambiarra” para realizar.

O ORA-600 pode ser um problema causado por diversos fatores, como:

• Falta de recurso de hardware

A falta de recursos de memória ou problemas de disco podem auxiliar seu aparecimento.

• Configuração do Sistema Operacional

Uma má instalação e falta de patchs no sistema operacional pode causar o ORA-600, e quando digo má instalação, gosto de me referir aquela instalação, NEXT-NEXT-FINISH.

• Falta de atualização do banco de dados

Podem perceber que a Oracle, quando lança um produto, possui diversos PatchSets, que é um conjunto de correções (Patchoffs) que é detectado pelo suporte da Oracle em acompanhamento de seus clientes. A falta de atualização só aumenta a sua chance de ter um amigo ORA-600.

• Utilização de News Features

Sempre que é lançada uma versão nova de banco de dados, com por exemplo, versão, 8.1.0, 9.1.0, 10.1.0 ou 11.1.0, (lógico, em suas respectivas epócas) e na sua aplicação começa a utilizar as features da versão (novos recursos de desenvolvimento ou banco de dados), **COM CERTEZA**, encontrará um ORA-600 em algum momento de sua humilde vida. Isso é porque o Kernel do RDBMS ainda não está “amadurecido” para executar “tal” tarefa, sobre “tal” sistema operacional com “tal” linguagem de programação.

Como sempre digo, ter um ORA-600na base de dados nem sempre é uma questão de desespero ou assinar a setença de morte, tudo bem que talvez possa virar algumas noites na empresa, mas isso passa. O ORA-600pode vim a qualquer momento, porque ele é resultante de diversos fatores como dito acima e **SIM**, para alguns tipos de ORA-600, podem ser resolvidos rapidamente.

Toda vez que se tem um ORA-600, é gerado um arquivo de trace no servidor, no diretório USER_DUMP_DEST ou BACKGROUND_DUMP_DEST(depende qual será o processo afetado). Nesse arquivo de trace, para quem é mais experiente, poderá encontrar as raízes dos problemas. Pode ser um “LAZARENTO” de uma instrução de SELECT que faz join com uma INLINE VIEW, que também faz um hash join com uma Materialized view e tem uma view com dblink que força o aparecimento do ORA-600, ou como pode ser um simples INSERT em tabelas IOT e assim vai, só com bastante analise iremos saber as causas. Mas onde quero chegar com isso?

Quando se tem o erro ORA-600 em mãos, devemos tentar entende-lo, como mostra um exemplo de mensagem abaixo:

ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

ou

ORA-00600: internal error code, arguments: [12209], [498], [], [], [], [], [], []

Podemos ter uma idéia de onde vêm o possível problema, a menssagem de erro é sempre composta por ORA-600 [argumento1] [argumento2] até o [argumento8]. Se estudarem a arquitetura interna do Oracle, o kernel é composto por diversas travas que fazem o controle, acesso e utilização dos dados.

Nínguem sabe dizer com 100% de certeza, se o kernel do Oracle é puramente escrito na linguagem C, mas dizem que possui algumas coisas em Java para os releases superiores ao 9i. Pois bem, isso não interessa até o momento, eu quero apenas exemplificar.

Analisando o trace gerado, podemos ter a idéia de onde ele vêm, como eu disse acima (por SELECT, INSERT, CREATE e etc), e sempre devemos prestar a atenção no primeiro argumento, pois ele que irá dizer em qual momento ou trava ocorreu o problema.

No primeiro erro mencionado, nosso primeiro argumento foi o kcbz_check_objd_typ_3, que internamente para o Oracle a trava KCBZ quer dizer Kernel Cache Buffer, então já podemos ir mais profundamente e pensar que ocorreu um erro no tratamento da informação durante sua passagem pelo SGA.

No segundo erro, como não existe nenhuma trava mencionada no primeiro argumento, e não envolve travas do kernel, pode ser algum problema apenas como manipulação dos dados ou quebra de integridade interna, e por isso, dá uma esperança que pode ser um ORA-600 com resolução rápida.

Ambos os erros, podem estar associados a um BUG da versão ou apenas uma má interpretação do banco de dados, isso, apenas olhando o erro e o trace não iremos conseguir garantir nada. É apenas um exemplo e modo de como podemos se comportar com um ORA-600 no banco de dados.

LEMBRETE

Sempre, **MAS**, sempre que tiver um ORA-600 em sua base de dados, acione de imediato o suporte da Oracle para analisar profundamente os motivos do aparecimento do problema e realizar uma investigação sobre seu ambiente, como mencionado, os fatores podem ser diversos e também pode ser ou não um real BUG da sua versão.

Estou apenas dizendo uma experiência que tenho no dia-a-dia e não me responsabilizo pelos seus atos. Espero que tenham gostado desse assunto e que possa entender melhor o motivo do nosso velho amigo ORA-600.

Abraços,